Grant Miller: All right, Adam, thank you so much for joining.

Adam Gross: My pleasure, thanks so much for having me here, Grant.

Grant: Cool, all right, let's dive into it. You have a pretty extensive background at enterprise software.

Adam: Are you saying that I'm old? I kind of feel like you're saying that I'm old.

Grant: Slightly, slightly old. So, tell me how you got into enterprise software. Where did it start? How did you start doing this?

Adam: Yeah, I think like most people slightly, completely by accident. I started my first company in the Web 1.0 era and 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 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 discover over a period of years, it absolutely was an enterprise software company, basically it was selling data warehousing solutions to, at the time, a lot of internet Web dot one O 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 how one goes about building software for enterprises, how one goes about selling and supporting it.

And so, 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 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 disciplines in our domain.

Grant: Interesting, okay, so I have definitely learned a lot from you in our numerous conversations throughout the last five years since I started Replicated. I always mention the conversation we had maybe three or four 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.

Adam: What did we talk about then? Remind me about that?

Grant: Yeah, we were arguing about on-prem versus SaaS and so it was a very, (mumbles) you did spend a lot of time at Salesforce.

Adam: Yes.

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

Adam: I'll share, as by way of introduction, a little bit of that story. I've been a pretty hard Cloud zealot now for almost two decades. And again, like the Enterprise go-to-market stuff in general, it comes from learning a lot of hard lessons. So, my first company, Personify, an enterprise software company, large, dealing on-prem what were effectively data warehouse deployments with incredibly immature technology that's obviously predated all of the things that we take for granted now in terms of databases, but there was only on-prem in that era. And man, one of the things I learned the hard way was how difficult it was to make customers successful, especially with what was a very complicated on-prem data warehousing, data analytics product. And so, by the time Web 1.0 ended, so now we're 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, 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 probably about 20, 30 million in revenue maybe, about 150, 200 employees and I was obviously very, very attracted to the Cloud thing, although they 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 in my previous company. So, there was actually some domain relationship there, as well.

Grant: Okay, interesting.

Adam: But yeah, and developed a whole bunch of Cloud religion, which only has become more reinforced over time.

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

Adam: 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 Sforce, now it's largely called Force.com. And my first product there, this was 2003, was the web services API. But then went on to do a whole bunch of platform-y things. For those of you who know Salesforce, everything from custom objects, app exchange, visual force, 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 specific for the Cloud because of course, to take a little bit of an aside, if you rewind to say 2005 in 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 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.

Grant: Oh, that's funny.

Adam: And the reason why that was the market view was nobody had 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. Like before Chuck Yeager did it, 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 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.

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

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

Grant: From a CD.

Adam: From a CD 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 technical concept and set of constraints and 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 app-dev points are available to me. So, how do I even begin to reason 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.

Grant: Interesting, okay. And so, in that model was part of the platform, right?

Adam: 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 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 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 demonstrate this, we would open up the entire addressable market for Salesforce in particular and SaaS in general. So, we were demonstrating and expanding the model as we were introducing each one of these new platform features.

And really the story of the first 10 years of Salesforce and the story of it going from a big deal being a hundred seeds to a big deal being a thousand seeds to a big deal being 100,000 seeds is really the story of the evolution of the platform. Because that's what helped it go from being able to meet a departmental or small business need to ultimately being able to meet as complex a set of requirements as you could throw at it.

Grant: 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 it had to integrate this whole work flow and process.

Adam: Yeah, they're really kind of two related, but separate ways to think about how the platform was 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 'other thing for Salesforce to become the center of an entire CRM ecosystem, which I think it has now. And those were all 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. 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 going to 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 a integration concern.

Grant: Yeah, okay, that makes a lot of sense. That's like the ability to as an internal developer at company X. Can you name some really of those early customers that--

Adam: Yeah, I'll give you a modern metaphor. A product that came out recently that I'm really impressed with is GitHub Actions. And so, if you think about it 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. That's kind of more of a business process concern.

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

Adam: One of the things I was very, very lucky to learn from some incredibly talented people at Salesforce including folks like Peter Gassner, who went on to found Veeva, is the aesthetics of building a platform as a product concern. And platform is such a 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 models and methods we use to do that? And how you choose to do that and ultimately how good a platform you create and the aesthetics that surround it is so, so important. Because those decisions are one, very hard to change, and two, 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 idea of platform aesthetics. We have it as developers, for different frameworks that we encounter. We could probably have a pretty robust discussion about the aesthetics and decisions between a framework like Express versus a framework like Django. 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 the enterprise application platform equivalent. But that is something we all are likely to have to work on and we're all facing in how do we think about exposing the right level of control to our customers without overwhelming them. Or worse, forcing yourself as the vendor into some kind of corner that is very difficult to extricate yourself from. So, I'm always, always, interested to look at how different companies approach that. And it's such an interesting time for platforms, this kind of platform evolution, in general.

Grant: You mentioned platform aesthetics. What falls into that bucket when you talk about it?

Adam: A lot of it is how you think about the right abstraction design. And abstractions are always a dangerous business because they always in some ways end up being leaky or they end up being some kind of trade off. But I'm a big believer that all platforms are really domain-specific. The word platform conjures this use case neutrality, which is probably not that helpful. So, in practice, everything that we think about as a platform really does have some implicit kind of use case problem or market orientation. Even 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 implicitly inside of these frameworks. And if you then 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, there tends to be some constraints around it and then it's okay, well, what's the right way of exposing control? What's the right way of articulating it? What's a well-designed set of Legos for this task? Versus something that's going to be completely wonky and not have that right blend of control and abstraction. I want to be able to do the things I want to be able to do easily, but I don't want to be able to get myself into a corner or have to navigate some incredibly perilous technical terrain in order to be successful. If that were the case, then as a user of your system, if the likelihood of my success is really poor because what you've exposed as the controls, if I had a right web assembly, 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, 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 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. Versus as a way of creating. And that, itself, is like okay, that's kind of thinking about it as a domain platform problem versus 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. But imagine if, instead of having Lambda, you had to fire up an app server or run a set of EC2 clusters, whatever or just to 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.

Grant: Yeah, yeah. And to your point there, I think we talk about serverless and functions to the service and the key thing that is so important is that eventing framework where it's all these different events that are happening that you're able to then respond to. That is it.

Adam: I'm going to 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 a CRUD traditional database, select star orientation to an event orientation. We are just at the early days of that happening and I think that is going to be super, super impactful for what happens with enterprise applications in general.

Grant: Where are the plays out? Or what are the implications? What's the--

Adam: Sure, at a minimum there're implications for how you're ultimately going to comprise larger architectures of multiple applications. And this has been a little bit of a distributive 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 and let me push some data there, kind of very sequel CRUD-y kind of stuff, that has a certain, maybe I'll surround the whole thing with some kind of work flow app. That's kind of the model that we've been in. When you think about systems 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 this Salesforce specific example, but the way I added some business logic to Salesforce is I did it by writing some Apex in the way maybe I added some business logic to Slack was by doing X. Slack is probably a poor example 'cause it's a newer company. But Workday did it Y, Circle CI 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 common customization integration components. Now that's going to have huge implications for how this whole enterprise application ecosystem is going to 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 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, you know, as opposed to having to think about these applications as being more vertically-integrated in silos and to themselves.

Grant: And so, if we think about that eventing within applications, (mumbles) my mind kind of jumped like the webhook is like a example. Is that sort of like a--

Adam: Yeah, for sure, for sure. I'll reference a talk that I did at SaaStr two or three 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. 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, that completely turned over the (mumbles) incumbent vendors. Completely reorganized the entire market, created trillions of dollars of new market opportunity, was a whole, big reset and recycle in the space. Well, there was an era before that, right, mainframe. Mainframe to the client's server was a kind of similar thing and that's not going to stop happening. So, the point is as product people or, in general, as people involved in the space, platform IT change is destinary. 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 opportunity categories are going to be created. And that's kind of, I just used eventing as one small example in that (mumbles) mix. I'll jump a little bit to the punchline. There's a idea of Cloud platforms that some people in the industry are incented to promote, which is to think of them as neutral core-infrastructure players. The mental model is this is a data center that exists somewhere else and this is 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 (mumbles) 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. My core belief is that Cloud platforms will be as impactful to the broader enterprise app ecosystem as the introduction of multi-tenancy and Cloud V one, if you will, was in relationship to client server. And you can say, well, wait. It's just servers in somebody else's room, right? Well, we could've said the same thing, that was the argument about SaaS and multi-tenancy. It's like, well, it's just your data set or mine, what's the difference? And of course, the difference is that these are fundamentally different platforms, different concepts, different abstractions and there ultimately will be a divergence between what are the current SaaS multi-tenant architectures in the next generation of enterprise app architectures that are going to arrive genuinely from a Cloud platform-native way. I think this is where you and I actually probably, that was the root of part of our original disagreement probably 'cause, 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 baseline capabilities you can rely on on-prem versus Cloud. They're just going to diverge. It's like saying that whatever's in my garage is ultimately going to be equivalent to what SpaceX has at their launch site. So, it's just like they're on different paths and they're going to end up diverging.

Grant: Interesting, but do you believe that there will be commonality between the different Hyper Cloud providers?

Adam: May be a controversial statement. I think the idea of commonality is both more sold and less important than it generally will be. What does commonality really mean? It means we're going to take the containers and run them, I can orchestrate a bunch of containers and Kubernetes in some kind of common way. And 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. How I manage security policies, how I manage network policies, how I manage access controls, all these thing that are incredibly important and are going to be virtually impossible to, nor should we even attempt to generalize, but even that, the container orchestration part is a tiny piece of the broader puzzle of all the systems and services I need for databases and data movement, all those kinds of things. And the idea that we're just all going to 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 lowest common denominator, broadly homogenized tools and services. I'm not, in any way, saying that the Cloud providers are going to lock it up. And we can look at the snowflakes of the world, and that's powerful evidence to see 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.

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

Adam: I feel like we're going to start having our argument again.

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

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

Grant: Yeah, and I do. Generally I think that big companies are founded on these massive platform shifts and paradigm shifts and so you find those and 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 work for companies that choose those and that's kind of how we decide. We kind of get skin in the game.

Adam: 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 the emergence of J2EE app servers in the 90s was an important shift. I would probably just say yes and more. That there are even bigger applications over the horizon.

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

Adam: Sure. So, I joined Heroku in 2013. The acquisition of a company had started called Cloud Connect, a Heavybit 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 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, I took over the rest of the organization. And Heroku, it was an amazing, amazing opportunity. It was an amazing ride. And--

Grant: So wait, Cloud Connect was acquired by Heroku or Salesforce? What was the--

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

Grant: Okay, got it, okay.

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

Grant: Got it. And in what year did Heroku get acquired?

Adam: Heroku was acquired in 2011.

Grant: Okay, so they've been around for a little bit and then they acquired you as part of this.

Adam: Yep.

Grant: Cool, great.

Adam: 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. 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 multi-modal go-to-markets, right? 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 knowing how to do self-serve. It's hard enough knowing just how to get free adoption of something. And effectively, at least for developer companies and 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 we don't have a lot of frameworks or guideposts to think about that. And how companies 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 think about the 08, 09, Y Combinator, Heroku, GitHub, that whole kind of universe of companies. I'd also previously worked at Dropbox, I'd kind of broadly put that in the mix.

And they were all fascinating companies because they all had this incredible, innovative bottoms-up freemium-style adoption to go-to-market which was incredibly innovative at the time. The SaaS world before was defined by free trial.

It was only with this kind of O8 generation 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, 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. 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, just kind of spinning up the 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 task really for the first time. So, when I started in 2013, about 95% of Heroku's business was just online credit card swipe. And when I left--

Grant: A couple of developers.

Adam: When I left in 2018, it was about 50, 50 online enterprise and the business had roughly grown 10 X in that period of time. And I was very lucky to be able to 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 freemium business with a enterprise, large-deal business in way that was mutually beneficial and complementary versus adversarial and destructive. Because again, rewinding to 2010, on one hand all these companies got this incredibly important thing right, a 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. And that is, I think, one of the most important things for developer (mumbles) companies to understand and work out. And it's not easy, but there's enough frameworks and patterns out there now that you can learn how to navigate that. But as you know, I'm sure you saw first-hand, it's hard to overstate how deeply ingrained that psychology was. And we had to go through a big organizational transformation to shake free of it.

Grant: Yeah, I think that definitely true of GitHub if you remember at that time.

Adam: For sure, for sure.

Grant: Hostile enterprise sales--

Adam: And I should say this, full disclosure, I was lucky enough to do a little bit of consulting work for GitHub after the acquisition, 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, there are some pretty core patterns of organizational dysfunction you can find. And I'm lucky that I've now seen enough different companies that hopefully you can spot 'em at a distance to avoid it, but it was certainly true of Heroku and it was certainly true of GitHub. And I asked 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.

Grant: Let's hear it.

Adam: This is where I kind of ended up. And this is kind of one of my framework pieces. 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 revolutions in go-to-market, that are clearly identifiable and segmented. And I think the kind of cognitive error that organizations fall into, very understandably, and again I lived it myself, is that they misapply the framework of one error to the error that they're in. And I'll give you a specific. So, if we decompose the entire history of enterprise technology go-to-market, kind of breaks down in roughly modern eras into three eras, right? 90s, 00s, and kind of 2010s. In the 90s, selling happened, well we kind of think about as Sales 1.0. A sale happened between a sales rep and a CIO on a golf course with somebody wearing Gucci shoes. Us, as technologists, are completely averse to that. Why? Because there's an assymetry between the buyer and the user. It has nothing to do with how good the product it, it has nothing to do with what the capabilities are or empathy for the experience. It just has to do with some shmoozy golf thing which we're developers, we don't play golf, so the whole thing is disgusting. And that was the 90s and that's pretty distasteful. But that's the mental model that a lot of us still carry around in our head. And, in fact, we're two generations away from that. What happened in the 00s with development of SaaS, is SaaS not only brought an entirely different technology model, it brought an entirely different go-to-market model. Because you're 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.

Grant: Interesting.

Adam: You think about it, 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 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-considered is in the Sales 1.0 era, there was a strict separation between selling to SMB and selling to enterprise because of those channels were very different. If you were selling to SMBs, you couldn't afford to go to golf course, so you had to go through the channel, which at the time meant being on the shelf at CompUSA or whatever the case was. In Sales 2.0, in the SaaS era, you could do, it was really co-emergent with search. 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. 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, collectively our consciousness kinds of ends. But the thing that happened was, over the past 10 years, an entirely new model. 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. And so, in SaaS 2.0, get a bunch of team use and then try and notch it up to the enterprise via seed and grow, which was the famous Salesforce motion.

In Sales 3.0, start with the user, you're driving adoption, you're not typically trying to monetize that, then you're trying to notch up to team, and then you're trying to notch up again to enterprise. And these things are all entirely connected. And if you think about 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-bloomed organization, are going to effectively have these three discreet, 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 free land. You've got some developer project that's super successful, people are using it, you're starting to talk about monetization. And then a bunch of VCs or board members or people like me come and talk to you and all of the sudden you've built a 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. And that's when you have a bad enterprise go-to-market experience. And so, how you balance that, how you build your progression from free to team to enterprise. Kind of broadly I think about this is Goldilocks go-to-market because the conversation I'm always having with companies is when are the right times to invest in each of those break points? When is the right time to move from free to team? Which really means building an online self-serve function. When is the right time to go from team to enterprise? And same set of questions, that's an incredibly expensive and organizationally-taxing move. And if you do it at the right time with the right groundswell of demand from your existing team customers, it will be smooth and easy and you're off to the races. And I was very, very, very lucky that we were able to orchestrate that transition at Heroku and that's how we ultimately built that enterprise business. But it can really, really be tricky.

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

Adam: For sure. In a way, open source companies were a bit more bi-modal. 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'd 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 that team or self-service motion in between. And what that led to was a bunch of over-rotation to enterprise. And this is a 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 a very small number of very large enterprise accounts. And they've organized their entire organizations around that kind of bi-modal model where that's going to affect how you sell, it's going to affect what products you build, it's going to affect your pricing. It's going to 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 going to miss out because it's so damn expensive to go for that enterprise first sale. If you don't have any existing support inside of the organization and you're just going to try and force a bunch of demand for this thing in there or awareness for it, good luck. Incredibly expensive, and that's again, very, very common anti-pattern, if you will.

Grant: And so, from a product and technology perspective if I'm trying to go from free to team to enterprise. So, when you (mumbles) in front of you which makes your skin crawl when you talk about SMB and enterprise, why is that?

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

Grant: Okay, so--

Adam: From a sales motion and value point of view, those are identical. So, you are hitting the SMB market by virtue of hitting the team market, 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.

Grant: Got it, okay. So, you should probably have an understanding that some of them are going to tap out. And that's the highest tier, but just likely some enterprise teams will tap out, as well, and they'll just stay at the team edition and they will never really go up to enterprise.

Adam: Sure, and the model depends on some small, it's very (mumbles), some small percent of customers moving from that team level to that enterprise level. But you only need, you're working off of an incredibly large freebase, you get to a smaller team base, then you get to a smaller, on top of that, enterprise base, but the dollar amounts are 10 X plus of what you're getting at the team level 'cause the kinds of problems that you're solving are so much more valuable. I'll take another aside to go a little bit layer deeper on again, what I think about this free team enterprise model or individual team enterprise model or sometimes I think about as the one-two-three 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.

Grant: Really?

Adam: Yes. And when I talk to startups, I kind of go in with this framework as my default. I'm open to sometimes, nine 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. 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 individual developer, that's a real creation act. Or even any number of the creative tools that are emerging now.

Grant: Sure, you want to be able to do it by yourself and--

Adam: Yeah, so that's creation act. Great, what is the value proposition on top of that? It's collaboration, it's somehow I'm doing on the team context. What makes GitHub so amazing? It's a team collaboration product. That's solving 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 also can have a lot to do with just compliance in a little bit more holistic sense of integrating with whatever the ways in which an enterprise works from 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 another one of these 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, where like if we can't solve problems for those people 'cause they only care about what happens on a golf course, so let's not even try, what's the point?

Grant: Press the man.

Adam: Yeah, and 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. Versus we can truly practice empathy and understand organizational problems and think about solutions for organizations that are going to behave in different ways. That idea of organizational empathy is so important to really 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 'cause they know that I love them. When I was at Heroku, we were in the process of adding some different compliance things to our own software engineering practices, for our own regulatory concerns. And we were pretty appropriately, in a way that I was proud of light on prescriptive engineering tools and processes and all that kind of stuff. You know, we tried to keep things as open as we could, but we did need to add some more standardize-issue tracking. And so, we used 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? 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've heard of Conway's law, which is that organizations shift 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 going to 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. That's like in engineering saying I don't care about the UI, get a smarter user, total cop out. So, it's a pretty common anti-pattern, as well.

Grant: That's really interesting. And so, obviously from creation, this to me feels like just the standard value in 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 you that would add into that team in terms of the future set?

Adam: I'd go deeper in thinking about the relationship between creation, collaboration, and compliance.

Grant: Great.

Adam: 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, if you think about LaunchDarkly, LaunchDarkly in the equivalent of kind of that individual mode, they solve an important kind of mechanical problem around feature flagging. It's like, okay, this is a convenience, it's a productivity thing, it's helping me create this thing. More result, that's great, but it's not that strategic. It's like okay, that's cool, but 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 future flagging they're doing? Really what they're doing is creating a framework for product and engineering to think about feature delivery together. That is a business process problem, that is a business maturity problem, that is a digital transformation problem. To just say, oh well, I can 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 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. And we had a similar thing at Heroku. People are familiar with the individual developer experience for Heroku and gee, isn't that nice I can push code that much easier and not worry about production? Yeah, that's unbelievably amazing. That was one of the more brilliant products ever created.

But the team guide proposition is really kind of distinct, especially when you think about 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. Which itself is a distinct problem from how you, as an enterprise, have a software creation capability.

So, at Heroku, when I started we had 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. But I was pretty damn sure there was one out there. And it was a constant exercise in 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 uncover it, but you have to have the intentionality of looking for it.

Grant: Okay, interesting. And so, this is actually somewhat contrary to part of the thesis of EnterpriseReady, which is just that there's a set of enterprise features that everybody should add in order to start selling in enterprise, right? You need Single Sign On (mumbles) access control (mumbles). 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 bowled onto these features, but it's really distinct for every product, find that thread and pull it all the way through.

Adam: The first feature of Heroku Enterprise, when we started it was all those things. SSO, RBACs, and those take up a lot of time and they're hard to build right and all the kinds of... And so, I'm not discounting that. 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 RBAC around it, absolutely, that's where you start. And by having that, that's the price 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. So, that is the starting point that is by no means the finish line.

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

Adam: Exactly. And the conversations that we were ultimately privileged to be able to have at Heroku, 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 in the holistic patient care business and being able to have a long-term relationship with a patient that is ultimately more outcomes-driven. Radical transformation in their business that's being driven by a thousand 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 than the business. How can a company and a product like Heroku Enterprise, in this case, help them with that transformation? Which, incredibly challenging, 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 the healthcare space. That's a business problem. And how can you really 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 (mumbles) which is already built that. Here you're just adding this on top. And 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. Who are we competing against then? We are competing against companies that only had that enterprise motion, that 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 the appetite and interest within our collective entrepreneurs for doing that.

Grant: Yeah, I mean I think that those problems, again, to your point, you have to have that sort of empathy. And I actually explain this sometimes and say the empathy, it's not just for the manager or the executive, but it's actually 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.

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

Grant: Exactly.

Adam: Because it's like we want these people to be able to use this 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?

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

Adam: I half agree with you and half disagree with you. 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, you will see some introduction of freemium. And I emphasize that 'cause I want people to have as kind of wide as possible in aperture in thinking about the difference between 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 I'm going to see some kind of work productivity happening on those phones in some shape or form. You can't stop and you shouldn't stop, you know there's obvious that doesn't mean we should be ignoring any of the essential compliance regimes, but at the same time, picking up the phone and having a conversation on an iPhone that I pay for myself is a business activity. So, I encourage having a wide lens that is possible because it will help you see where those opportunities for adoption at the individual level are happening.

Grant: Yeah, I guess and to your point, this is also like people will adopt some software in their personal lives that they didn't want to see in their professional lives.

Adam: 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. And it's funny because I have that conversation with new entrepreneurs and they're like, well, they said they'll never use it. And I'm like, don't worry, they always say that. But I understand it's new information for some people, but history is clear. And even in the past couple of years as if you watch that curve accelerate, the future of on-prem is not... (laughs) Again, I have a long-term view but there's Cloud prem, that's a thing. I'm trying to be a little more accommodating. (laughs) You know, you can't beat history like that.

Grant: 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 the (mumbles), people think about data privacy and data security in a different way than they did five, 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 they process, more like data stewards or data custodians. And so, there's this inherent responsibility and I think this is 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 and GDPA side, but it's also just how we individually think about our data and data ownership and I do think it's having impact in the enterprise ecosystem.

Adam: Here's where you and I, 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 in 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.

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

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

Grant: Perfect.

Adam: 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. Like we are in one and wow, is it getting crazy out there. And if you think about the tenancy model for Herga, Postgres, or RDS. My control over that data and 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, that's not multi-tenant in the way that we think about a Slack or a Salesforce. 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 manually operating a bunch of those boxes. They have these incredibly sophisticated control planes, which I know because I worked with some incredibly brilliant people who wrote them, 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 (mumbles) patch to all of them.

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 right and my data gets sent to three different data centers. These are incredibly sophisticated pieces of software.

Which leads me to two 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. It's something new and different, that's one. Two is, when people tell me about Amazon just taking open source software and 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, it is a better ecosystem and it's a whole better thing by virtue of the fact that their service is like RDS. I'm not imminently familiar with all the Cloud player's policies, I don't want to speak out of 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 reprinting it without any additional value add, that is the frame that I reject. So, that's my controversial statement.

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

Adam: Yeah, and isn't it fascinating? And I'm a control plane guy, right, so I naturally want to 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 really going meta, and that control planes are the app servers of the future. Right, because it's all about 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 innovation there. But that lens of thinking about the control plane as a key fulcrum of value, I think that's something that is not in the consciousness.

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

Adam: Yeah, and even beyond the whole open source thing which I'm just saying I'll 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, I clearly don't believe that because there's just never been... Back to our earlier 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, if it's going to work for something, it has to not work for some other things.

Grant: 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 this sort of meta-level. And it's why I think the most powerful, and this is kind of the operator thing is the most powerful thing about operators is we're extending the Kubernetes API. So, you're taking--

Adam: Platform for building platforms.

Grant: Yeah, that's what it is.

Adam: Did they get that out of some J2EE, (mumbles), JSR document or something?

Grant: I don't know.

Adam: I mean, come on. I want a platform for building platforms, too. What a classic, I could not disagree with any framing of a platform more. Because the whole idea is that, my whole idea is that platforms are domain-specific. It's like at some point what are we creating, turning machines? What's going on here?

Grant: I mean the thing that I believe to be true is that particularly--

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

Grant: Well, I think that... I talk about Kubernetes as the patterns and primitives of reliability. And I say that generally, we have in the industry now a pretty robust number of security primitives. If you wrote your own encryption, I read then 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 Mesos and Docker and Tupperware and Peloton, all these things are being reintroduced into sort of a best practices for reliability and that's kind of coming through with Kubernetes.

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

Grant: Well, that's because it's the greatest thing in the world, okay? End of podcast, I'm just kidding. (laughs)

Adam: I encourage all Kubernetes people to help me get more religious. (laughs) Clearly I need it.

Grant: Okay, so 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 and really helping people understand 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. And what should I look for? What are the things that I should pull in particularly for really great go-to-market executives that are going to help a company like Replicated, which we're trying to hit, we're 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?

Adam: Yeah, hiring is obviously is tough, and there's a whole thing, but I'll happily share some of what I've learned on 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 hard to parse a space of marketing and salespeople it is when you're sitting, having built some product and you're largely insuring your product organization and how challenging that can be. And the main thing I would advise is intentionality. And what I mean by that is, going back to how I was saying before, if you have this kind of one-two-three 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 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 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. 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 paper, stuff like that. Tends to be kind of very data, 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 your first marketing hire or even your dominant, you're bringing in that kind of person into an organization that's going from free to team, that's a total mismatch. 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 and (mumbles) 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 having a mode mismatch. Because it's so hard to detect. 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 two quarters. And you have all this friction, you don't know what the hell is going on and you're like, well, I don't trust marketers 'cause I'm an engineer, but really I should counter that feeling. And it's all confusing inside. And so, it's a really 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 want to learn about these things, I have the right background and skills to think about this. Okay, great, but just be really, really intentional. There's 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. 'Cause 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? What is the entire holistic journey 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 a million dollars 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. And that is the common case is you don't have a theory of the business, you've hired a bunch or people, they're just doing what they did at their last job, and 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 then 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 at all, just chaos case, that is so spiritually and financially draining for an organization.

Grant: And so, how would someone go about trying to uncover their theory of their business? What's the exercise that you would suggest that they, the questions that they actually ask themselves and look at?

Adam: At the simplest level, it should be pretty simple, which is to overuse the phrase, what's the customer journey? Holistically? The simplest customer journey you can imagine, which is a little cliched, but okay. I'm going to write a really cool open source thing, I'm going to get a bunch of notice about it from great content around it that I get to the front page of Hacker News. That's going to drive a bunch of downloads. I'm going to 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 team's 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 bucks and there's a credit card to get them to do the thing. And my expectation is I'm going to get a million people to give me their email address and I'm going to convert 10% of them and that's going to be. It doesn't have to be right. It's much more important that it's holistically plausible than it is correct. 'Cause the whole thing is you're going to constantly learn and iterate and drive, 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 doing gated content or 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, because you're salesperson is going to start crapping on your marketing person because they're not delivering these hand-wrapped leads that are ready for golf dates. And there now, you as the CEO are now managing the fact that you've got this tenuous relationship. Then you fire your CMO because your salesperson says they're not working and now you're like, you've lost seven 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.

Grant: So, when you were CEO at Heroku, you were thinking through what's our theory of the business and you were sharing this with the team and you were iterating on it every--

Adam: Absolutely.

Grant: Yeah, okay, interesting.

Adam: 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 one-two-three model at Heroku. And it's a whole art, just like Sales 1.0 is art, Sales 2.0 is it's 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. 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 that kind of clarity and intentionality to build it the right way and get everybody aligned 'cause you're going to get a whole bunch of people aligned to do this thing. 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 a 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. Sales isn't happy with marketing and vice-versa. You're happy with neither of them. 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.

Grant: It's interesting when you think about the model you talk about one-two-three. Do you think it's possible today to do a pure, top-down enterprise sale?

Adam: Absolutely.

Grant: Okay. 'Cause that's not one-two-three.

Adam: It's not at all. We're talking primarily about developer-facing, freemium, bottoms-up startups. 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.

Grant: Has it changed in the last 10 years? Has that model changed? Is it still--

Adam: Honestly? I don't think so.

Grant: Interesting.

Adam: I think the way that you do it, and I see some of these companies. It's very targeted, CEO dinners, lots of field marketing, executive engagement. I think in 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. You're in video, 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. That's top-down, I'm selling to probably the board of the company that's buying in to all the economics. I don't know anything about these businesses, but 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.

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

Adam: Yeah.

Grant: 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 going to want to use it anyway and they're going to want to use something else.

Adam: There's a mode of developer and enterprise as opposed to one-two-three, as opposed to just developer, team, enterprise. And my guess is that Pivotal was probably more in that mode. Which I think is--

Grant: (mumbles) things they were doing.

Adam: 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 it's important and it gets you a little bit of groundswell, but you haven't mechanically connected to the operation of your business. And I would, out of ignorance, probably assign it to that category.

Grant: Okay. Feels like maybe in the security ecosystem there's maybe a little bit more of that straight top-down, 'cause there's more centralized buying within the (mumbles).

Adam: Or there's certain kinds of infrastructure decisions. If I'm buying WiFi access points, I don't do that on a individual basis. There are a whole set of cases where there's an assymetry 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 bit more closely which is productivity software. Because Suites, I-E Office 365 and G Suite are sold enterprise-wide top-down.

Grant: True.

Adam: 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.

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

Adam: 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, they sell to a team or an SMB by throwing in some ad cents, credits, or whatever the case is.

Grant: Interesting.

Adam: I'm on shaky ground with this analogy.

Grant: But it also kind of highlights the set-up point, which is a collaboration tool is not necessarily very useful on an individual level.

Adam: 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, 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 apply that reasoning to ourselves.

Grant: And more importantly probably, have this within your team. Have this regularly and be clear about what your current theory of the business is at any moment and revisit it every month, every two months, or at some cadence. Probably faster at the beginning and more quarterly and annually at later on if you're publicly traded.

Adam: I'm telling you, I've spent a lot of time with this one-two-three framework and anybody who's worked with me who's had 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 what are the metrics that you need, 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 really helpful prior art that you can borrow from.

Grant: Yeah, it definitely makes sense. And then your point is your messaging, your product, everything needs to capture these three things and you should be--

Adam: No.

Grant: Oh, no?

Adam: That you, as a business, need to understand which of those three you're operating in. One more thing about it is they're almost three distinct, but connected businesses. So, maybe you're engaged in all three, maybe you're engaged in one of the three, but if you're doing a, and it's not to say that you can't do marketing activities that apply to all three or they kind of over a little bit, I'm not going to be, it's not 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 going to use, how I do marketing is different for those, how I do customer support is different for those. And I'm going to have the intentionality of saying okay, I'm building this for one, two, or three 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 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 have a PM who's holistically thinking about okay, if I'm in free, my job is to drive sign ups and activation, ultimately activity. So, 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 conversion, retention, whatever those things are and I'm going to be thinking about whatever those things are. As well as 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 you're going to have different functions, marketing, sales, support, whatever that are going to 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 not working great, how do you help make it better? It's like, okay, we're going to do three meetings. Once a month, we're going to have our free meeting and we're going to have representation from marketing PM, maybe sales, whoever's appropriate, and we're going to talk holistically about the business and we're going to talk about it in that way, around those metrics and we're going to talk with marketing, we're going to about product, we're going to 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 going to do the same thing for team. Next, we're going to do the same thing and talk about enterprise. And if you don't align that around those different business lines, then whatever sales is doing, whatever marketing's doing just becomes kind of a functional view and it can be very difficult to align. And then sales is pissed because why is marketing working on this thing that isn't for them and yada, yada, yada.

Grant: Yeah, it's broader, it's more than just, it's really the whole framework, it's the theory of business, it's like nowhere each part is operating with... And then the other interesting piece here is I think with this framework it allows you to not just look at 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. In the beginning, maybe you were not focused at all on three, you're just doing one and two and then you realize, okay, we're on top of funnels so we can focus on one for a while. And you'll do new features around that or something.

Adam: 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 three of these. We, at Heroku, when we were a hundred million dollar business, when we were a sub-fifty business, we weren't it all. So, I'm not saying, gee, where 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. You're likely thinking about when do you do team, and getting back to this Goldilocks idea, the hardest question or discussion I have with CEOs is typically when do you make that investment. And how do you make that investment? And when do you move from 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 kind of frankly kind of check myself because I can be, 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, 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,000,000. That's the closest I can come. At Heroku, we were materially more than that before we made that move. So, when you even see a company that's doing like three or four million, you're like God, you guys are doing great, let's go! 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 your capabilities with teams and they're ready. And they're ready to help you go in that enterprise journey.

Grant: Yeah, and there's a bit of a luxury of time there 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'll move us from three to six, you're probably going to do it at that point, unless you have just huge amounts of funding or runway that you're like, no, we're going to stay super-focused on staying in one and two and push that off for another two years until we're really ready to focus on it.

Adam: I think that's really helpful for you to bring it up because it's exactly the kind of hard, non-pithy discussion that one has to have. And we've all lived that. I remember even at Heroku there were times where customers were willing to write us huge checks before we had HPPA compliance and we're like, okay, what can we do 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.

Grant: Yeah, unless they're still alive.

Adam: Yeah, there's survivor bias. I don't know if the survivor bias though, which way it points.

Grant: I believe that you basically do whatever you need to survive and sometimes that's just kind of obvious.

Adam: That's very Donner party of you.

Grant: Yeah, exactly, yeah. (laughs) But no, as a startup you're like, we know we need to get this done if we're going to keep going. It's just all debt, 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 you're accepting it and you're saying, yep, it's debt, we got to pay it back later, but we need it now.

Adam: 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. 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 is over-rotation to enterprise. You've got a successful free, open source community online thing and your CEO will come in, and I'm not going to name names, and you bring in an enterprise sales team and you start knocking' on doors and 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.

Grant: We just do this thing.

Adam: We just do the thing. And then what you end up doing is skipping team. 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 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 what is instead of a 200K, 500K deal, a 2,500K deal, it should be transacted online. Now the economics of your sales 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.

Grant: Yeah, that's interesting.

Adam: And that happens a lot.

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

Adam: 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.

Grant: I think this part of it is just the reality is there is a lot of really great advice and this is really sound advice and so I think that someone thought we talked about it, the theory of business, the pieces are really important and there's just a lot of times the rules are like--

Adam: I'm a frameworks guy. Conjoined triangles of success, that's what I'm peddling.

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

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

Grant: Awesome, thank you.