Ep. #45, The Enterprise Grind with Ed Anuff of DataStax

Grant Miller: All right, Ed. Thank you so much for joining.

Ed Anuff: Thank you. This has been long overdue.

Grant: Yeah. I wanted to have you on for a while. So let's dive in.

Tell me a bit about how you got into enterprise software.

Ed: You know, I actually jumped into enterprise software fairly early on in my career.

In the late nineties, I co-founded a startup that was doing enterprise portals and jumped both feet in there and learned a lot of the hard lessons of doing enterprise stuff.

Grant: What was an enterprise portal? What's the context there?

Ed: Sure. So, you know, the idea was, well now I'm actually realizing that like all the reference points are probably like many years out date, but you know, you used to have your personalized start page, like MyYahoo and things like that.

You'd have all of your personalized content and those were super popular in the consumer internet.

Yahoo had their site and Excite and Infoseek and all of those companies that, well, I guess Yahoo's still around, but --

Grant: Barely.

Ed: Exactly. And I'd actually been working in the consumer internet space.

I'd been at Wired running the HotBot search engine and we'd been trying to build a portal strategy around that.

Grant: I think you know this, but HotBot was my favorite search engine when I was in high school, so that just to make you feel extra cool.

That was the one. I might have even been in middle school. I can't really remember.

Ed: Let's go all the way. You were in elementary school.

Grant: Yeah. Yeah. It was the first search engine that I was ever really introduced to, so I was like this was great. Search is cool.

Ed: I was actually reminiscing with Eric Brewer because he was, at the time, the founder of Inktomi that built the search technology that we used and so this was a partnership between Wired and Inktomi to produce this.

It's really funny just 20 years later ending up working with him at Google afterwards.

But back then, this stuff was pretty cool. Anyway, as part of that experience, there was this idea that you would create this personalized start experience for the web of aggregating all this content and delivering it into sort of this single integrated experience.

And so myself and Oliver Muoto, who was my co-founder at the time, we said, "Look, if there was a way to make this something that that enterprises could use for their employees or even for their customers where you could pull together a bunch of content from various services and integrate it into this, that would be a valuable thing."

It turned out to actually be a pretty big deal. There were a number of companies that pursued this.

Epicentric was our company. In fact, Edith from LaunchDarkly was one of our engineering leaders back then.

Grant: Amazing.

Ed: Yeah. So it's this very small world, but yeah, so we were doing that.

There were other companies. Plumtree. There was TopTier. Pretty much everybody got acquired.

TopTier went to SAP. Plumtree went to a company called BEA that then became part of Oracle.

We got acquired by Vignette, that then got acquired by OpenText. So all this stuff is actually still in use.

Of course, Microsoft got into this space with SharePoint and so on. But that was my first real exposure to enterprise.

And I got into it like everybody does when they get into enterprise, which is to go and say, "Oh, you know, it's just all about selling to businesses," and you quickly get that whole education that goes into okay, what does that all mean?

Grant: How big did Epicentric get before you were acquired?

Ed: So in terms, I don't remember the details on where our revenue was at and so on.

We were like a four or five person company. We were getting ready to do an IPO and the markets crashed and all of that.

It was your classic sort of Web 1.0 story of get big quick.

We had a bunch of big customers. Excite, in fact, used us for their Excited Work Portal.

Verizon used us for everything. A ton of companies did.

The software is still in use in a bunch of places, you know, when you go and log in and your healthcare providers and telco companies and so on.

They keep that software around for like decades.

Grant: Yeah. I mean, is there like a modern sort of version of these kind of things?

Sometimes these technologies products that started years ago, if you think about Webvan became Instacart kind of thing.

Is there like an example of sort of the enterprise portal today? Like what would be the modern equivalence?

Ed: The interesting thing is actually a lot of what--

You know, going back to patterns, this was something that I actually had seen over and over in my career, which was that typically from the start of the internet age, enterprises have learned how to engage with their users, their employees, their customers, by using really sort of the interaction patterns that they see within the consumer internet.

The consumer internet taught enterprises what applications should look like, what architecture should look like, really everything.

So in the case of Epicentric, for us, that's where I saw that pattern.

I said, "Okay, like you can literally go and take what people are doing in the consumer internet, figure out a way to package it, and some form of that will be a viable enterprise strategy."

And so at Epicentric we became part of Vignette and Vignette was very much about taking the content publishing that a bunch of the early news websites had gone and packaged up and they took it to the enterprise.

I was at Six Apart, the blogging company.

I was running the enterprise platform and we were literally doing the same thing. You saw that all of the media companies were saying, you know, the way that you want to communicate with your audience in a more agile way is through blogs, right? Now you see every site uses that blog template format.

At the time Six Apart, and of course WordPress, took that pattern and brought it to enterprise.

Apogee that I was at later was, again, the same thing like companies were going and saying, "Let's look at the way that Twitter is managing connecting to developers out in the greater internet. Can we leverage that idea?"

And then you had companies like Apogee, Mashery and Layer7, and now you have Kong still following in that path, which is to go and say the way that the internet companies do it is the way that the enterprise companies are going to be doing it five years later.

That is a constant pattern. Like people go and say, "What should I do for my enterprise startup?"

And you go and say, "Okay, take a look at what people who are in the forefront, people who are doing tech typically for internet consumer purposes, find that technology and figure out how is that going to be democratized for all of the rest of the global 2000?"

And you'll be onto something.

Grant: What are you doing now?

Ed: Well, you know Grant, about two years ago had the opportunity to go and join Chet Kapoor, who was the CEO of Apogee, who I'd worked with for a number of years, and we brought Apogee to Google back in 2016, they acquired Apogee.

I spent a few years there integrating Apogee into Google Cloud.

Then Chet got contacted by DataStax to be their new CEO and to bring DataStax, which is the company that makes Cassandra, the open source database, and bring that to the Cloud. And that seemed like a pretty cool challenge.

So I've been at DataStax for the last two years. We launched Astra, which is our cloud database platform as a service that takes Cassandra and makes it dead simple to use and run in the cloud.

We've taken Cassandra, we've rearchitected it, separated compute and storage so now it runs serverless in the cloud.

Now any developer that wants all the scale and power of Cassandra can go and do it, pay as you go, dirt cheap to use.

It's really cool. I've used Cassandra for a number of years.

We used it at Apogee. Actually I was using it at the startup that I'd founded before I joined Apogee, so love the Cassandra database.

It's just amazingly powerful, but it's always been super hard to run, to operate at scale, and so we've made that dead simple. And so that's what I've been up to.

Grant: That's great. And you're the Chief Product Officer, right?

Ed: Yep. Yeah.

Grant: Was that your role at Apogee as well?

Ed: Yeah, so at Apogee I was the head of product strategy and so did that. It was a little different a model.

We didn't have a chief product officer at Apogee but effectively was the person figuring out the product strategy for our APM management products.

Grant: Very cool. It is really interesting that all of these companies that sort of are inspired by consumer technology--

You see even like design and other things kind of, you know, flow through into enterprise software, and to your point, even a lot of the infrastructure software companies that are out there really, it's not the way that Google is giving you a search experience, but the way they're running it behind the scenes ends up becoming the sort of technology that becomes the foundation for the next generation of applications.

Do you think that it's important to spend time at these consumer internet companies in order to see what they're doing?

Or do you think it's more like you don't have to, you can be in the enterprise, you can sort of just like read the white paper, see what people are open sourcing?

How do you think the best way to kind of engage or be aware of those things is?

Ed: Well, I think that's a separate question.

I think it doesn't hurt to have a point of view on what do engineering practices and operational practices look like in a live fire situation.

I think that you won't get that purely from an enterprise background and a lot of vendors don't get it.

But you have to do it by having done a stint at an internet company.

I've had the privilege of, I think four times in my life, being at internet companies where we were on the firing line of like if your system doesn't work, your businesses doesn't exist. Right?

Like had that back at Wired with Hotwired and HotBot.

Had that at WidgetBox, which pivoted and became Flight, but we were delivering live internet services.

Had that at Six Apart with our Typepad service. And then obviously while at Google, saw that with Google Cloud.

And there is ... I think that that's super valuable to have been exposed to that. Is it the only way to get it?

No. I think that you can get there through conversations, reading about it, understanding it, but I do think it doesn't hurt.

Now I would say for a lot of the current generation of people who are going and doing enterprise startups, a lot of this knowledge is now permeated, but I would say that like 10 years ago, when I would look at an enterprise startup, I could tell pretty clearly the difference between the ones where nobody in the company had ever had to carry a pager and deal with an outage of some sort versus the ones where they did.

So it doesn't hurt. Is it essential? I don't know, but I do think from an operational infrastructure piece.

On the flip side of things, I do think for a long time getting the user experience component of it was hard to find.

Nowadays I think you can get that experience, you can get in terms of creating user experiences, in terms of understanding what people are trying to do.

You know, in fact, I think oftentimes the internet companies are probably maybe not even the best place to get that perspective, but if you were to have rolled the clock back 10, 15 years, it probably was the only place you could find people who actually had really sort of lived and died by the quality of their user experience.

Grant: Yeah. That's a great point because I mean ultimately these consumer applications, if they weren't usable enough, they just didn't get the adoption.

You didn't get the scale. It didn't work. You had to test your way to really usable versions of software.

And then turns out those lessons are pretty applicable and you kind of like figure out the patterns again and apply those forward.

And you're like, okay.

Once you've landed on an experience that makes sense to consumers, it'll almost inherently make sense when it's applied to enterprise software, right?

Like the same patterns.

Ed: Yeah. I mean, I think the patterns definitely do apply.

There's an interesting tangent we could get on, which is we are getting to the point where a lot of infrastructure technology comes pre-baked with some sort of assumptions in terms of how people go and manage their software development teams and so on and processes and we start to get into a harder conversation about how realistic is that?

We could probably go on for hours if we get onto that one.

Maybe we should.

Grant: Yeah. Give me your thoughts.

Ed: Okay. Well, I think one of the things that has been a real challenge in bringing technologies into, specifically IT.

People don't say I'm bring it into the enterprise, but it's really about IT.

There are often a lot of assumptions that IT is software engineering.

And so the idea is that somehow that if you were doing IT right, and you had read all of the various books, the various projects and so on, that you're running your modern IT shop and it looks exactly like the same way that Google looks from a software engineering standpoint. The reality is that is not really the case and may never be the case.

The way that a software engineering team looks within each of these companies in an ideal situation will look very similar, but the way that IT systems are run and deployed looks very different.

In fact, one of the insights that I had when I joined Google and we went and looked at how are a lot of the business systems run?

We found that they definitely run them in very agile ways and so on, but a lot of it ends up looking a lot like the IT systems that you would see at any other enterprise.

Now where the difference would be is in how are the actual end user facing services built.

Those are built in a very dramatically different way.

You have to be careful in projecting the adoption of the processes and the acquisition of the skills when you start to go and look at how an enterprise is going to work.

It will happen, but it happens on its own timescale.

Some of these things may never happen.

These companies are just not organized that way. Oftentimes people are overly optimistic.

I think we saw this, for example, in the early days of service mesh I think is probably something that a lot of folks who followed the technologies that you and I are interested in, probably looked at.

Service mesh has been very successful in certain areas, but there were a lot of assumptions that it would play a role within how enterprise integration scenarios were being addressed, like how do I go and get my CRM system to go and talk to my accounting system and what have you?

It turns out that that definitely was not the place where service meshes, or for that matter, microservices in general, were playing a major role.

The reason is because those are not software development domain problem.

Those are very much about taking two off the shelf or possibly in the Cloud systems and gluing them together and it's done as a sort of one time, do and forget type of project that's built and not through a classic software development cycle, whereas a lot of the assumptions within a lot of service mesh thinking were that you would have a very different team that would be doing these things.

Perhaps a very modern SRE team. But certainly the assumption is that your software engineers are in the loop at an appropriate level.

So again, this is one of these things where you can't assume that even though people need to adopt all this technology, adopting a business process, adopting a people process is a pretty steep step.

Grant: Hmm. Okay. And so the lesson here, and this is actually super interesting, is that corporate IT is different from the engineering department, right?

And so these are two disparate orgs and corporate IT is generally, e ven at Google, you're saying, it's sort of like not run the same way that a software development team is run.

And it's not about the same practices around true, like sort of the SDLC, the software development life cycle, but instead it's about, I mean, I guess I'd say like, how do you solve a business problem probably somewhat quickly and fairly reliably?

And that's more the MuleSoft sort of integration tooling than it is like a service mesh, like, in your own, you're writing code to do these things kind of tooling. Is that accurate?

Ed: Yeah. Essentially.

Look, I think the other important lesson is that IT is not monolithic because the other piece that you'll get is a bunch of people coming in and saying, oh, that's absolutely not true.

Like for example, going back to Google, I mean it's a hundred thousand person company.

There's probably, please listeners don't come in and inundate us with emails and tweets saying, Ed doesn't know what he talking about.

I certainly don't.

All I can speak to is one specific project that I looked at where I was like, oh, that looks very similar to a classic IT project.

By the way, it's the same thing, you know I think you've probably seen this yourself.

You go to many Fortune 500 or Fortune 100 enterprises and you'll talk to a team that literally could have walked out of, and they're doing the same quality software engineering that exists at Google.

I'm not trying to say that they're not.

What I'm saying is that on the other hand, just because you find a team at, and I'm purposefully not naming companies because I don't want to--

Grant: At some big bank.

Ed: Yeah, say some big bank or whatever.

Just because you will find one team that is fully embracing modern DevOps processes or fully doing everything the way that we would all generally agree is the best practices, doesn't mean that the rest of the organization is.

And so you always have to go and say, "Okay, what are the standards and best practices across the organization?"

To bring this back to what does this mean for enterprise founders, as you try to go and time this technology, any specific thing, and again most of what we deal with these days is in the cloud-native ecosystem, you have to go and really make sure that you're engaging with the right team.

Otherwise, you may read all these blog posts and say, "Oh, this big bank is all in on Cloud Native."

I'm just going to walk in on this team and say, "Hey, I've got this platform and it deploys on top of Kubernetes", and they'll be, "Yeah, we're not the team that uses Kubernetes".

Do you have a--

Grant: An OBA, yeah or do you have a--?

Ed: Exactly. Yeah, so that's the other thing, I think you find is that this stuff is all sorts of interesting pockets and stuff.

Grant: Yeah.

No, the idea you that there's a heterogeneity in terms of how, even just within a single organization, the way that each different team will do things, and there's not generally standardized practices around most processes, right.

It's, well we have a procurement process, but we don't necessarily have a standardized application deployment process or integration process or there's a--

When you get into the details, it becomes sort of the problem of that team to solve in whatever way they want to solve it.

Ed: Yep. What I would say is that the closer that you get to where the business or the enterprise interacts with their users, their consumers, their buyers, that's where you start to see that the technology strategy ends up being more uniform and much more progressive, right?

So if you want to go and find where Kubernetes is being used, look at the team that has to deal with, that absolutely needs the elastic, scalability, and reliability around that.

Don't assume that the backend system that is dealing with say employee-facing systems, or other pieces, is going to be where you find that stuff.

But everything starts to look the same the closer you get to the web front end, the mobile front end, the stuff that goes out on the internet.

That's where the people who are succeeding have gone and adopted the best practices and, to use a buzzword, if they're building digital products, right?

It doesn't matter whether they are a retailer, or they are Google or Netflix.

They're all using Cloud technology, they're all using Cloud Native.

And they're probably adopting a lot of the development practices that go with it.

As you get away from that, you get things that are much more project-based.

Where people go and say, "Okay, I'm building this application or I'm building this integration."

Maybe it's an HR portal or something.

"I've built it, I've deployed it, now I'm done."

Now the engineers go off and work on something else. For a true internet-scale, internet-facing, user-facing application, you're never done with it right?

Grant: Right.

Ed: So in those situations, that's where you'll have a standing engineering team that's working on it, going completely.

For example, why does Google retire an application?

Everybody complains when they do, but why did they do it?

Well, they do it because, at an internet company, you wouldn't have something that's out there that you didn't have a team working on right?

Grant: Right.

Ed: And the day that you get to the point where you go and say, "I don't want to have a team working and revving this thing," is the day you shut it down.

It's an anti-pattern to go and keep the lights on for an internet service.

That's how you get into trouble, frankly.

Grant: Mm-hmm.

Ed: Whereas within IT, you have a lot of applications that you do keep the lights on, where you go and say, "Okay, this is some backend system and as long as I'm able to process an invoice or something on it, perfectly okay to maximize the life on it, even if the developers that built it are no longer with the company."

That isn't an anti-pattern, that's just useful life of a system.

And so that's the part where, when you're bringing this stuff and you're dealing with enterprise, you're navigating this landscape.

Am I dealing with this stuff that's on the cutting edge, that has active investment, has development teams?

That stuff is going to look the same, that team is going to be ready and often really eager to go and deal with cutting edge stuff.

Grant: Yeah. I think it's a really interesting insight here, this idea of timeframe based and I'm trying to figure out how--

So you mentioned project versus standing team.

How do you describe the two different sort of models here of engagement?

How do you think about those? What do you call that?

Ed: Yeah. So we actually use a framework that we call project program platform, that we actually use in our sales process around this.

So first of all, a lot of things within the enterprise are done on a project basis, a lot more so than people give credit for.

And so those are applications where a team is formed, they have a defined scope.

They are delivering an application, maybe for internal or external use.

They know what it is that they need to build. They want to go and get it done.

They'll reach for their off the shelf technologies.

This is where a lot of the stuff that companies do from a developer adoption, and a developer enablement really pays off because what happens is your enterprise developer is a great developer, but they know that they need to get this thing done in two months right.

So unless there's something that can't get solved with existing tools, they're going to reach for the stuff that they know.

And if you've got a startup, if you're trying to sell into that, a lot of what you're communicating is how you remove anything that would be an impediment to them getting it done in a 90 day time frame, and them getting up and online really quickly.

You have your program that is typically a-- Well there's typically at least one business stakeholder that is trying to get something done.

Oftentimes this might be a company's for ANT commerce or something that has a strategic impetus around it.

There are multiple teams that are involved.

And so in that case the goal is, how do we go and have impact?

How do we go and compete?

What is it that successful internet companies do? And can we use that too?

And so you have a business technologist, a mini CTO, who is often the person who drives that, and their title differs from company to company, but these are really innovation driven.

And then you've got the platform decision, which is where you go in and say, "Okay, we're going to standardize."

And typically there may have been one or more projects, and often in many cases, dozens of projects that have been built, and each project selected their technology.

You may have had a program that became really successful and now it's being mainstreamed.

But now the CIO comes in and says, "Okay, we need to now get some leverage because this is a standard technology. I want to be able to go and hire for this. We're going to go and make this a key skill that everybody we hire has to have. And I want to go and deal with a vendor that is going to be able to stand by us for all of these decisions."

And it may or may not be the most technology forward vendor, it's going to be the one that has the best success at addressing enterprises as business needs.

And so typically as a startup, you are probably playing at the project or program level because those are in the situation where the project is really, "I got to get it done."

And the program is, "I don't care what the standard is, I want to go and what makes me the most competitive?"

But by the time you get to the platform level, you're talking about how do we reconcile, and how we standardize?

I don't think Kubernetes ever played really that strongly at the project level.

I actually think, and a lot of people pointed this out, that a lot of these things were at the project level, that's where things like the Cloud services and even things like Heroku would go and play.

I just want to get it done. Really dead simple, straightforward tools.

At the program level, that's where people went and said, "Okay, I'm a major retailer, I want to use the same technology that Amazon uses."

And so they'd go and say, "Okay, how do we go all in on Cloud Native and build something around that?"

And that's where you'd have really some innovative leaders.

And then now we're at the point where a lot of that has now graduated to be on the CIO's plate, where they're saying, "Okay we've done a bunch of these projects and programs and they've been successful, but now I want to standardize on it."

And then that's now where they're going and looking and saying, "Okay, who do we standardize among our big three or big four vendors that are going to be our platform technology?"

And that's where you've got the OpenShift, and Anthos, and Tanzu, and all of those are really bidding to be the CIO platform choice.

Grant: Mm-hmm. And so when you think about these, I'm guessing they inform what you do for go-to-market, marketing, the whole spectrum.

You have to look at this early on in order to understand, what are we doing? Who are we trying to influence?

Ed: Absolutely, yeah.

And again, this has been the technique and pattern that we've used, and that I've seen work at previous companies and so on.

These days your projects are going as much as possible to self-serve, right?

People come in and you want to remove all the friction, you want to give people easy access to stuff, you want to go and do as much as you can from a developer adoption standpoint to make people just reach for these tools and have a comfort level.

So yes, you've got your sellers there, but they tend mostly to focus on onboarding rather than going and having a quota sales team there.

At least from what I've seen in the conversations I've had, and what we've seen directly, you want to help everybody at that level.

You don't want somebody coming in and saying "Oh, I'm going to go and optimize for what I think is the big deal."

You want to figure out, how is it that you can address everybody who's doing any project?

Don't start going and saying, "Oh, that one is too small or that..." Whatever, just get them using your stuff.

When you get into the program stage, that's where your sellers first engage, that's where your deal sizes are going to get to the point that they support a direct engagement model. And so that's where you go in and start to have a more high touch model.

Typically what the conversation looks like at that point is where you're talking to them about how people who have succeeded have done so, from an architecture standpoint, from technology choices, from insights gained.

Your selling approach is very consultative in that approach of going and saying, "Yeah, this is how Netflix does it, this is how Google does it, this is how an Amazon does it."

And you're often talking to enterprise architects, and you're talking to these what I call business technologists.

But like I said, whatever's on their business card varies very widely. And then when you're talking to CIO, again it's standardization, and the end result is an ELA, an enterprise license agreement.

What the CIO wants to know is, they want to make a bet on your company, and they want to go and say, "Okay, we are going to get a tremendous amount of efficiency by optimizing around this. And I'm going to be able to get the best possible economic terms."

As a startup, you may get a few of those, but unless you're really good at that, what you want to be doing is building your projects and program wins.

Grant: Yeah, it's interesting.

I actually think one of the challenges for startups, and we felt this very early, the first call it year replicated, I know some other early stage founders felt the same way.

There's a step before project even.

Ed: Yeah.

Grant: Which I'll follow your P, I'll call it playing.

Ed: Yep.

Grant: And that's just when a CTO or somebody comes in and you're like, "Oh man, I got this really high level person at this great company that's playing with my tool."

But there's no project behind it. They're just like, "I want to know what this thing does, I want to understand how maybe I could use it someday down the line."

But that's something you have to be aware of that, it happens right.

Particularly in open source, all these different places, people will...

Inquisitive, curious folks who are just going to dive into something and want to understand it.

You know they've heard somebody had a good use case, and it's working well for someone.

And they're, "Wow, this isn't really... We might need this in three years."

And so they kind of shelf it for that time.

And then a project to me was always, somebody has a goal, they're trying to get something done, and there's a timeframe to your point.

That's a great thing to see, when you start to evolve to where there are projects.

In our business it was, "Hey, we're modernizing our application to use Kubernetes and we want to be able to deploy it out to our customers."

You'd be like, "Amazing, that's what we do."And it wasn't like, "Hey, we're exploring this as a path, and maybe we'll do it someday."

And so you see that evolution, I think it's a really good signal that the market timing has gotten close to where you are. So...

Ed: Oh my God, I'm glad you brought this up. Yeah, no, this is definitely the case.

These are the things, that as a startup founder or just anybody who's trying to get something off the ground, this is what's going to screw you up really bad honestly.

Grant: And also create false horizons where you're, "We're almost there. No, we're not." False horizon. Keep going up the mountain.

Ed: Absolutely. This is the part that's going to wreck you, and by the way, if you're a small startup and you're dealing with this, I'd love to get into how you got through this, because what ends up happening is--

This is where enterprise SAS, for applications, is dramatically different than enterprise infrastructure.

Grant: Mm (affirmative) interesting.

Ed: Yeah.

If you go and talk to people who do growth marketing and everything, and you read all the stuff in the SAS ecosystem, everything that you read about growth marketing, growth hacking for applications, you need to throw out the window when you start actually doing growth hacking for infrastructure.

Because, if you've got an HR app or whatever, a CRM app, a large percentage of the folks that log in, they have some intent to buy.

Grant: Yeah.

Ed: They're not just logging in for the sake of it. And of course, again, we'll get everybody coming in saying, "Ed, you don't know what you're talking about."

Which is always true. They'll be, "no, no, no, we have that same thing in the SAS apps."

But I will tell you, with infrastructure, much, much higher percentage.

Somebody's goes on hacker news and says, "Oh, I've got a new database, or I've got a new container, or orchestration."

Every developer logs in and it's, "Oh, I'll check it out. What the hell? Why not?" And they'll have no project.

Grant: Yeah.

Ed: But you'll see it and you'll be, "Oh, I saw so and so from big bank, oh my God, we're on our way. Look at the interest."

And so the qualification process, we do this, a big part of our effort for DataStax with our Astra databases of service is about, is there anything indirectly or directly that we can do to just determine, do they have a project or not? Right?

Because if they don't have a project, if they don't have a timetable for something to go live, then it's great.

Hey, welcome in, welcome, try everything out, do things .

I'm perfectly happy to have you there, but if you do have a project, then our goal is, what can we do to help you select this technology?

What can we do to get you up and running on it?

What is your deadline? What are you trying to achieve?

And so if you haven't, and as I said, either directly--

We'll have popups and everything we can in the onboarding experience to try to get you to signal to us that you've actually got a project, and we do our best infer it algorithmically, because otherwise you'll be looking at the data and you'll have no idea what's going on, you'll be scratching your head, you'll be saying, "Oh, I've got all of these people, did they churn? What are they doing?"

And so if you can't separate out the people who have no project.

There's a lot of learners, which is great, we love learners, people coming in, students and stuff, absolutely want you learning how to use Cassandra, and using our service.

But when I'm looking at the dashboards and I'm trying to say, "Okay, how many of these people are becoming paying users?"

If I can't sort out which set of these folks is...

Again, they're learners, they're tire kickers, they're folks that are coming in and investigating, from people who have an active project, then I have no way of managing my funnel.

And that's ultimately what it comes down to, you have to do some form of funnel management to try to figure out--

Grant: Or even optimize your product so that it works better for--

Ed: Yeah. Ideally you want to be, and this is the debate you always have... any user is a valid user, but if they had no project to begin with, then you could be debating all day long, you'd be like, "Oh, the data shows everybody gets to the screen and they do nothing."

And it's like, "How do you know that they actually would've ever did anything?"

They had no data to load. In our case again, with a database product, we're like, "Oh, should we have a data import tool?"

And then the question is, how do we know they actually had any data?

That qualification process, that will drive you nuts if you don't get a handle on it.

Grant: And you actually try to do a lot of that, you're saying, in the product, right? So using, you said popups.

What are the implementation details there that you're getting that signal from?

Ed: So this is the interesting thing, which is, a lot of the time, and this was interesting...

This is one of these ones where from a self-service standpoint, a lot of people beat themselves up and they think that self-service means for example, no contact or whatever.

So the reality is, it is perfectly okay to engage with people.

Things like Intercom, the chat button, all of these things, self-service just means that you're letting the product as much as possible speak for itself, but it's like when you go into the Apple store, there's still people there to answer any questions that you might have and what have you, right. It's just--

Grant: Very true.

Ed: They're just not there pushing on commission, going and saying, "Hey, do you want an Apple watch with that? Right. They're--

Grant: Can I put you on the Apple subscription plan for the next 30 years to get every phone and device we release. Yeah.

Ed: Exactly.

So one of the things that you often see is that people try to go and over-optimize for trying to infer, they want to do everything from a data science standpoint.

And then you're like, "Oh, I need a..."

And then you never have a big enough data science team, and for a lot of startups, the data science team is just you in your spare time.

But even in cases where you do have that team, they're overloaded.

And so, one of the things as a product manager that I often point out is, it is okay to go and pop something up and go and say, "Hey, do you have a project? Would you like an onboarding expert to help you? Do you have a go live date? Do you have a project? Do you have..."

People start worrying about the friction on that, they don't want to put in the signup page, where somebody goes and has some buttons of going and saying, "Hey, are you a student? What's your experience level?"

They don't want to go and they're like, "Oh, we're going to lose signups if we do that."

Well, the reality is that you'll end up with a bunch of signups that you don't know anything about.

And it is actually better for you and your users for you to have a little bit more of an insight as to what your users are trying to do, than to just say, "I don't want to have any signup left behind."

You will end up with a bunch of signups that are just nothing, somebody signed up and they don't even remember.

You'll interview them three months later and they'll be like, "Oh, I don't even remember signing up for your service."

And so when you get into that trade off, don't be afraid to introduce a little bit of friction for the purpose of qualification.

Now, of course, when I say this, then the marketing team pricks up, it's like, "Oh yeah, by the way, can you have them say what the size of their organization was? And do they have a budget and all?"

No, that's not what I'm saying.

Grant: And where did they find out about us?

Ed: Yeah. And where did they find out? Yeah.

Grant: A question that no one has ever answered accurately on any form they've ever filled out.

Ed: Yeah, exactly.

Grant: What's the funniest answer I can put down.

Ed: Exactly, yeah. No, I don't mean that, I'm talking about stuff specifically to the user journey.

It is okay to go and ask them, "Hey, do you have a project that you're trying to launch? Or are you just a student?"

Perfectly valid, because I guarantee you, if you're like most infrastructure technologies, very good chance that 80% of your registrations are students.

And again, there's nothing wrong with that, you sure you definitely want students in there.

But you're not going to send a nurture email every two weeks to a student to go and say, "Hey, I noticed you haven't done anything this week."

Maybe you will in your automated system, but I don't think it's going to be--

Grant: You want to put them down a different path, really, you want to put them down a student path.

Ed: Exactly.

Grant: Bring this into your class, do something interesting.

When you look at what Qualtrics did, in terms of using students to drive the adoption of their software through enterprise over the course of a decade, and it was amazing, right.

See to it so that every student graduates knowing how to use this software and then they're like, "You don't use Qualtrics here at this company, I'm going to sign up for it right now."

You're like, what? They can.

Ed: Yeah. Put them on a different nurture path, there's a different type of thing.

But on the other hand, for example in our business, if you are a Cassandra user and you've got a Cassandra project, then actually the clock is ticking, we have 30 days to convince you to use it.

And again, that means if you couldn't figure out how to hook it up to your app, their nurture email needs to be suggesting to you the documentation on how to do that.

If we see you loaded up a bunch of data, but you didn't seem to make any calls, nurture email needs to do that.

If we did see you did a bunch of traffic, then the nurture email needs to talk to you about scalability options.

Grant: For that kind of nurture system, are you using a product?

Or you built things internally for that? What's the best way to go about building that kind of nurture, event based nurture flow?

Ed: So like everybody else you're perpetually in building and rebuilding your system.

Actually, what I really liked was your anecdote, because when I used your stuff, I was like, "Your nurture emails are really good."

And you were like, "Well, I write them."

And I was like-- I've told that story to so many people.

Hopefully, it's still true. It was at the time when we talked, I think.

Grant: Yeah. I think they were just personal emails from me to you maybe who knows? I don't know.

Ed: Could have been.

Grant: But what do you have under the hood? What are you using right now? Is there a...

Ed: Right now, we're actually using a bespoke system.

Grant: Okay, great. So bespoke system--?

Ed: For the developer stuff. For the developer stuff, the business stuff goes through like Marketo and all that stuff.

Grant: Yeah. One of those things, right?

Ed: Yeah.

Grant: But built internally right now, based on--

Do you use any system under the hood to manage different events or is it hooked into going into CRM to tell you what's going on, or?

Ed: So, because for us, what we were seeing was that there were specific set of events that we needed to look for that were in application.

So ultimately, what it's doing is it's basically setting flags in a profile. And then the profile is just part of an email system.

I actually don't know what the specific email system it is that we're using to send them out.

But the stuff that collects it is stuff that's in app because it's in the UX tier, right?

So I would actually love for us to have used something that was more comprehensive in an off-the-shelf way.

We just didn't find... It was easier for the level we were at that where it was easier just to hack something together.

Grant: Yeah. And then you're not sending like a thousand different events into some system about all the things that your users are doing too, so.

Ed: Yeah. But I will say, look, I will say our branch points in terms of the nurture tracks we have about a dozen different ones.

Ultimately, what I hear from other folks is that they build extensive sort of taxonomies of user categorization over time.

And so we'd love to get to that level.

Grant: Yeah. Yeah.

I mean, I think the thing that we messed up on for a long time was we didn't actually continue the nurture campaign for new folks that were invited to the team.

So our product as a multi-person product.

And so you would invite team members and we weren't following up with those people in a similar nurture campaign.

So they were sort of like whoever signed up first got the emails and we weren't doing similar kind of educational and informational emails to the folks they invited.

And I think that's a mistake.

I don't know if we fixed it yet, but it's something we have to get done, right?

Because that's how you spread out in an org, build more experts who know how to use your product and feel more connected to it; know they can reach out; know they can actually engage, so.

Ed: So we use the presence of multiple people in an org as a big signal, because ultimately again, part of what we're trying to do is just build a model on.

How serious do we think they are, right?

And the more serious they are, the more that our head of growth marketing will write a personal email.

Because ultimately your funnel is coming down.

You're going to get down to a set of 20 people that you're paying attention to.

On a weekly basis, you're sending email to.

You're actually going and saying, Hey, how are they doing with that? Right?

Grant: Yeah, of course.

Ed: So multiple people in an org is maybe different in your usage model, but for us, that's like, suddenly you want to sit up and be like, okay.

Grant: For sure.

Ed: It's funny actually, when we look at it, the other major signal for us is do they use Intercom?

If somebody uses that in app chat correlates very, very highly with the likelihood that they're actually going to buy and scale their usage.

Grant: That's, that's a very good testimonial for the Intercom folks.

Ed: Yes.

Grant: And I guess it makes sense because if you are--

It's kind of like, if I'm at Nordstrom and I'm walking around and I'm not really going to buy anything, I'm just kind of looking and I'm not really in the buying mood, right?

I'm just like, yeah, I'm just looking at some stuff.

It's like I'm not going to bother somebody.

They ask me, do you need any help? No, I'm fine.

If I'm like, I need to buy a suit; I need to do a bunch of--

I'm here to buy some something specifically, then I am going to ask for help, right?

Ed: Yep. And so the key thing for us was to... So we took all sales out of that cycle.

So what we said was, let's go just purely to--

Like, unless you ask to talk to a salesperson in our self-service channel, you're not talking to a salesperson, you're talking to an onboarding engineer.

And because what we found was that when we looked at the data, the sales people didn't accelerate things one way or another.

I mean, salespeople are very valuable.

We've got a big sales team, but in that particular stage, getting them high quality technical answers is the best thing we can do for them.

Grant: Yeah. Yeah. That's so true.

And then, at what point would a seller come in to help move it up the chain either?

Do you close it as a project? Do you try to move it to a platform or do you just...

Ed: No, We'll close. So project should be able to close at sell service.

Grant: Great.

Ed: Now that said, the user will signal that they want to talk to a seller.

Now, typically they'll do so by going, it'll typically be that they'll be looking for either some features that might be like your premium enterprise feature.

That's something that they want to turn on. They need some sort of...

Grant: Some SAML thing, some role-based access control, whatever--

Ed: Exactly.

Grant: The core enterprise ready features that we rate this whole website about. Yeah.

Ed: Yeah. Well, but the thing is, is that what you don't want to do at the project level, and this is the part where it'll drive your seller's nuts because your goal, your philosophy should be, I want to onboard them onto my technology.

What a seller will want to do is they'll be like, oh, I want to supersize, the deal.

Well, at this stage of you working with the user, the goal isn't to supersize the goal is to just get them to...

And if they feel that's where you're going, it's going to be a big turnoff, right?

So your goal is just, can the product speak for itself?

And so that's why the point of going and saying, do I put a seller in the loop, is probably not a good idea, unless at this point, the user has basically identified and gone and said, "look, do I get a discount if I commit to a year's usage?"

Or things like that. At that point, okay, now the buyer has gone and said, "I want something that's not on the standard menu."

In which case, that's great. That is where you've got a real sales process.

Otherwise, what you're much better off to just have, again, what we call an onboarding engineer who is fully capable of making sure that you're using the right stuff and their interest is just about the user to succeed.

Grant: Yeah. No, that makes a lot of sense.

I mean, how do you determine, though, how much onboarding to invest per customer?

Do you kind of wait that out and say like, "oh, we expect this account" because, I mean, you only have so many onboarding engineers in so many hours in the day, right?

Ed: You typically want to--

There's a couple of different ways of doing this.

So first of all, if you've got the situation where all of your onboarding engineers are being swamped and you may be in that situation.

I think you're going down a different path. I think that what you have to go, and at that point and go and say, one is like, that might be a good problem to have because maybe that there's too much demand.

On the other hand, if you're swamping all your onboarding engineers and you're doing so for a small amount of users, then you may have a problem with general product usability.

And again, it may be somewhere in between on that.

But if it just turns out that you've got so much demand that you don't have enough onboarding engineers, then that's a good problem to have.

Grant: Yeah. I mean, what's the average kind of engagement that an onboarding engineer would spend with a customer? Couple hours?

Ed: That's a good question. In our case, we're looking at it.

I think it's typically a half an hour or less and if the issue is configuration and set up and things like that, those are good interactions to have.

I mean, again, the next time around we'll document it, we'll be fixing it in our UX. We'll be doing that sort of thing.

So they don't tend to stretch out that long if they do, it's still worth doing, because that conversation you're finding out who that user is, if they're an active prospect.

So again, part of this is you're doing your qualification.

If you're spending two hours and it's a student or personal project, then maybe that doesn't make sense to do, right?

Like you probably-- On the other hand, if they're like a SaaS application or something that's being built on your infrastructure, I mean, why wouldn't you spend two hours?

Why wouldn't you spend more time than that?

Grant: Yeah. So, okay.

So you do sort of scope it a little bit and you just leave it up to the onboarding engineers to determine, invest more time here or kind of try to send them down a continuously more self-served path.

Ed: Yeah. I mean, there's a difference between from an onboarding standpoint is different than your support situation, right?

Grant: Okay.

Ed: If what the user is doing is looking at general enablement, you do have to have, and again, this is the part depending on where you're at.

If you just don't have the enablement content that you can direct people to.

I get the short answer's going to be you very quickly find all the limitations of your content.

Grant: Right. Yeah.

Ed: Right?

Grant: All your docs. Yeah. You're like, oh, why isn't this documented?

Why is this not? Why is this edge case not mentioned, right? You're like...

Ed: Yeah. I got to say, this is where everyone's experience because I've been in that stage where--

Well, so what you'll end up very quickly is the good news on all this stuff is it's going to shine a light really quick as to what matters and what doesn't on your docs.

You may be in a brutal situation your first couple of weeks.

If you don't have all the docs in there, you'll be like, oh my God.

One way or another, somebody has to be able to learn how to use your product to use it.

You're either going to you having-- And when I say onboarding engineer, I mean, if you're a new startup, I mean, it literally might be you on the other end of the phone.

I've definitely had to do that on previous startups. The onboarding engineer.

Hi, I'm Ed, your onboarding engineer. My separate job is founder of the company, but Hey.

In which case, yeah, then you're living it. And then you're like, okay, wow.

We need a quick start guide, pronto.

Grant: Yeah. We've written a few quick start guides in our day.

Very true. I mean, and this is for us.

It's also where I think, as an industry standardization is super helpful, right?

So like, as protocols get standardized as people standardize on ways of doing anything, it's like the interoperability and like Hey, I have something.

And you're like, yeah, great. We work with that standard, or that protocol.

Load it up in this way and do X, Y, and Z. And it's like, oh great. Now I can see something working.

It might not use all the functionality of the tool or the product, but think about this, even the telemetry and kind of monitoring space.

Things like open telemetry and these other things that really, I think unlock companies in terms of onboarding just to let folks get value from the product.

Ed: Yes. It's interesting because we spent the first hour just talking about what I would call the enterprise grind.

I think there's a lot of interesting insights when we're comparing notes on these things.

But if you really want to succeed, you need to get leverage in the model and leverage in the model comes from the fact that, for example, you have a distributed system, like for example, the first 10 years of Cassandra.

Cassandra is a cluster deployed database, right?

You can't just deploy a single node, at least not for production usage, which means right out of the gate, you need at least three nodes and most people are doing so with a fleet of nodes, right?

So for the majority of the life of Cassandra, it's been like these bespoke tools that we've shipped or the open source project or that data stacks as a company that we've shipped for people to do this.

We would love, and it's a big part of our strategy has been to; let's get Cassandra on top of Kubernetes because now all of this stuff for dealing with your nodes and your pods and everything can just be standardized. Just use Kubernetes, use Replicated, use--

Now we've got a way of managing this fleet that doesn't have to be like, let's reinvent the wheel for distributed system management. And so that's where you suddenly get leverage in the model.

And so a lot of what we've done, we started an open source project called K8 Sandra that was entirely around going and saying, let's reimagine Cassandra on top of Kubernetes, so that now there's leverage on how to do this t hat if you are a Kubernetes expert now, you can go and do a Helm install of Cassandra and everything is going through the operator.

And we've automated out a lot of the pain that made Cassandra just so painful for the last 10 years.

And so you always like, that's where standardization and yeah, you a founder need to always be going and looking and saying, okay, is there a way that I can go and remove a lot of the pain?

If you don't, then you're back to the enterprise grind.

And the enterprise grind means, I need onboarding engineers. I need great documentation.

Everything that you do, that's non-standard, you're a hundred percent on the hook for one way or another for solving.

Grant: Such a great point.

I mean, from my personal experience, I'd say, to actually decide, okay, we're going to embrace all of these standards partially is a little bit scary because you're basically taking things out of your control.

Ed: Yes.

Grant: Right? And you're saying, okay, we're going to trust this community.

We're going to trust this thing. And maybe it's not your vision or your not the ideal way that you wanted to do it.

You're like, oh, we don't have to work around how this thing works.

And we're kind of tied to this other system, and its success.

And so, that's scary and you're like, we could build a better thing right underneath the hood.

And this is like everybody built their own orchestration and scheduling systems that orchestrated all these different applications for years before everything sort of standardized on Kubernetes.

And I'm sure people have-- Cassandra probably has some kind of internal orchestration, the original version, right?

That like, it was hard to rip out and hard to be-- And people are like, oh, I don't want to lose that, right?

Because that works so well for this.

And so, now we're only going to be able to work with folks who--

You're only able to work with folks that are using the system.

So it's hard to sort of, as a founder, be like, no, everything is about standardization, and that's going to pull you out of the enterprise grind to your point.

It's also going to give you-- You're playing to where the future's going, because ultimately, fully bespoke systems are so unappealing over time and they just don't scale.

You can't hire around them. You can't all these things.

So you want the least bespoke solution because it simplifies things.

Ed: Yes. Well, I mean, if you're a founder, if you're a CEO platform strategy is the hardest part of the job.

And you can't delegate that. It's where all of your leverage comes from.

And I can't think of a single big success where there wasn't a bet, a serious bet on platform strategy at the heart of the product strategy.

Like you went and said, "okay, I'm all in on this one thing." And if you bet wrong, you're going to be kind of screwed.

And unfortunately, I can go back, like back when we were doing Epicentric, this thing called enterprise JavaBeans that the old timers might remember, was this big thing.

And I remember having this conversation with our chief architect fella by the name of Dean Moses, who I later went and founded and another company with.

And then Paul Emory, who went and later was-- He was our head of engineering, went to join a bunch of other companies.

And so we having this convers-- I had drank the Kool-Aid on enterprise Java beans.

And I was like, so you're saying enterprise Java beans are hoax.

And these two guys were like, they're both like, hell yeah. And I was like, okay, fine.

We're going to miss out. We're going to miss all the platform leverage.

And it was later, it was a complete debacle. Spring framework later came in.

And for people that followed this stuff, you may have heard of spring and pivotal labs was really, before they got known for cloud Foundry was really all about spring.

And if you're in the Java world, that turned out to be the right bet. And there's a lot of examples like that.

And so in the early days of a lot of things within Kubernetes and in fact, we still see some of these things with--

There's still a lot of unanswered questions in service mesh, but you'd see everybody going all in and saying, oh, it's this thing.

And that's the part where at least personally for me, that's the part that keeps me up at night where you're like, okay, we're going to make a bet.

And if you bet right on the platform, then your life is going to be dramatically simpler for your users, for you, for your technical debt.

You are going to get vast acceleration of your business and you are going to save millions of dollars, but your engineering leaders and oftentimes this is all in one person, you are both your technical leader and your product leader in one person.

On the flip side, you always want to control your destiny.

I know plenty of startups that have gone and said, "oh, I'm going to bet on this next big API or standard that everybody's gone and talked up."

And then it goes nowhere.

Grant: This is where creative destruction lives, right? It's like, if you make the right bet, then you win.

And big companies are afraid to make the bets.

And so if enough people make a bunch of different bets and the big companies don't make them, then a small company that made the right bet wins.

It's not every company that made a bet. It's just the one that made the right one, so.

Ed: Well, exactly. And so platform strategy and ecosystem strategy. Those are the two pieces and...

Grant: So ecosystem strategy in terms of what ecosystem you're going to be in, or ecosystem--?

Ed: Yeah.

Grant: Okay.

Ed: So platform strategy can apply to both from an ecosystem standpoint.

Like if you go and read textbooks on platform strategy--

Grant: Which I have done.

Ed: Yes. And you start getting into things like multi-sided markets and all of that.

I usually actually refer to that as ecosystem strategy to differentiate it from how most technologists think of platform strategy, which is what do I build on, what do I leverage?

And there's a lot of overlap on this, but sort of choosing which technologies, which APIs and so on, those tend to be your technology platforms.

There is definitely, like I said, a big overlap with the ecosystem components of it.

That's where you tend to get into these, as I said, sort of, what are your market synergies?

But yeah, I mean, you probably spend all day thinking about these things as do I, or anybody, because just a lot of landmines there.

Grant: Yeah. I mean, I was just looking at the book that I read that actually I think is somewhat of a textbook on platform strategies called the Business of Platforms.

Ed: Yeah.

Grant: Strategy in the age of digital competition, innovation and power by Michael A. Cusumano.

Very good book does kind of break down a lot of these things and kind of to your point gives you all the different sides of how platforms work and uses Microsoft in a couple of different examples.

But that is a really useful sort of, I mean, it's good to have a vernacular, right?

So if you're thinking about how to do platform and you make your product and your engineers, your other folks read it together sort of a nice way to then be able to talk about the things you're experiencing.

Ed: Yep. I'd shout out to anything that Marshall Van Alstyne, has worked on and platform scales was his book.

But the flip side of it for a technologist perspective, one of my favorite books is this book called Racing the Beam.

It's part of the MIT platform studies series where--

It was actually, this was the first consumer technology platform because it was a case where you had the video game console and technically it was your first preceded home computers and everything was where a lot of the lessons of software platforms were learned.

And so I always plug that one as one that people should read.

And it's great for engineers and technologists because a lot of the lessons, a lot of the platform studies books, these days get into a lot of sort dry economic theory.

Whereas, this stuff gets down into the bits and bites where any engineer would appreciate it as well.

So it's a good on-ramp for engineers as well, who want to start thinking about these things.

Grant: Yeah.

I've found myself kind of going back through, it's hard to call them memoirs, but they're like, somebody that worked at apple that wrote about how they did software engineering in apple or someone who worked at Microsoft writing about what they did there.

I mean, or more recently, the working backwards book about how Amazon does their kind of product management stuff is really great.

So it's really getting into the details of what they do that I think is helpful.

And there's so much knowledge out there, so much to consume that you can sort of really understand.

And then, again, I think sharing these with your teams is a great way to create vernacular, to create a common set of knowledge you can then work on and then move from.

So you have reference stories, because sometimes I know in your career you've worked with some of the same people many, many times, so you have a lot of oh, it's another one of those.

There's another one of those. You can kind of point back to past experiences, but if you don't have that as a team, then you want be able to use a frame of reference of different--

Sort of like common stories that you can reference and say like, oh, we don't want to do that.

We don't want to be-- Our team already advantaged together. It's like leadership principles kind of stuff, right?

So you can refer back to those things as we're trying to avoid those traps or et cetera, so.

Ed: It's really interesting.

I think that if you are prospective founder, if your--

People who are trying to sort of navigate product and business strategy, going and getting the common vernacular, understanding all of these sort of important lessons in the evolution of the industry help.

It is the part when people are breaking into the industry.

They hate how much sort of the... And I remember this when I was first doing it, but I got started by reading a bunch of these books.

When I got started, I had read all of these books on the founding of apple and all that.

So I had just sort of grown up in reading all of these articles and, and, and books and all, but if you haven't, then everything ends up sounding like that Star Trek: Next Generation episode Darmok where everything was...

The aliens all talked through this literary analogy.

And if you didn't sort of rock it, you were like, what the hell? It didn't make any sense.

So I do think building it into the culture where you sort of have everybody read these books or stories or histories.

It's a good way to sort of introduce it.

And the other important part is that everybody who's really passionate about technology knows some of these stories, but they don't know them the same way.

So that's why I do think your point in creating the common vernacular is really useful because what'll happen is, this will even happen.

I'd say at this point, if you're working with...

Well, just in terms of where we are in terms of the tech industry, a lot of people right now who are in a number of the leadership positions in the tech industry, so people who are the old fossil dinosaurs like myself, a lot of us are people who sort of grew up in the shadow of when Java was becoming a thing.

And so you'll hear a lot of analogies that'll go back to the early Java enterprise days.

And so that's the part that ends up being this common language.

But if you didn't live through that, if you didn't see the Java platform wars and Sun's standardization attempts, and Microsoft's attempt to fork it or the Java enterprise stuff, and that whole time period, then you might not get what are all these people talking about?

So it's useful to go back and pay attention to that. On the other hand--

Grant: Well, on the other hand, the problem is it's not like the founding of Apple, so there's not compelling movies and books written about it, right?

Ed: Yes.

Grant: So it becomes fairly hard to access some of that information.

There weren't podcasts about those things to that point, it wasn't like...

So it's actually interesting to think about, how do you even get some of that history?

You have to be willing to crawl through some old books to get there. That's the best way.

Ed: I think so. On the flip side of things, again, if people are worrying about that it's a double edged sword, like--

Grant: Trying to take the past and apply it to the future doesn't always work. Right?

Ed: Yeah.

Grant: Sometimes it's like, there's a lesson that you learned you can't.

But then now it's the time that it would've worked. I always say this to my team.

I'm like, "Look, we've tried something like this before, but I'm 100% percent willing to try it again, because now could be the time when it's different. So let's do it."

Ed: Yeah. I would say that it's like the false negative is a bigger problem.

People go and say, "Oh, that never worked. We tried it, it didn't work. Oh, that was tried by so and so it didn't work."

And oftentimes people do it with incomplete knowledge.

They go and say, "Oh, that was tried and it didn't work."

And what they understand that it was like, "Oh, I actually worked in a bunch of other settings that you personally didn't happen to see."

It's always interesting to, when an idea like that happens, I always get excited because it's like a great opportunity to go and like, "Hey, let me go to Wikipedia and actually reread a little bit of the history and see if maybe my remembrance wasn't exactly correct."

But yeah. I mean people like to overly pattern match on everything.

Grant: Yeah. It's one of those.

I think, I just remember from my early work experiences, people being like, "Oh, we've already tried that."

And writing it off as one of the most frustrating things, because it was, well, I clearly think it's going to work now.

And I have different information than you did before.

It's like, we have so much more knowledge and information today than we did at any other time previously.

Inherently, we have all of the world's the past knowledge.

Now there's an argument you can say that we lose some of that knowledge.

And so history repeat itself to some sense, but if you're a student of the history, then you can watch out for those things and try to avoid making the same mistakes, but not lose your spirit of like, "Well, let's try it. It might work this time." Right?

Ed: Exactly. Exactly.

Grant: So this is going to be like the least enterprise software five, 10 minute discussion.

But one of the things you told me about three years ago that I just found to be completely mind blowing and barely believed it was true was, basically when France had the world's first full computer system that in every home they had a PC on every desk or every kitchen counter before Microsoft was even founded or something.

What's the story about that?

Ed: Yeah. So that was Minitel.

Basically, this was back in the early '80s that the French government decided that they should have an online service that we should have access to.

And they had things like e-commerce, and access to content, and all of this that preceded really at least what we generally think of as the rise of the online services that started to happen in the late '80s and early '90s when AOL entered its heyday.

And so it was really interesting to learn about--

The only reason why I knew this of course was because, when I was growing up, I was reading Bite magazine and it was before the internet. The only way you would learn these things was by reading the computer magazines. And so they had all these articles on this thing.

And so I was aware of it, but then in the early days of the internet, I did have the opportunity.

And actually one of our early investors back in Epicentric was France Telecom.

And they originally were getting very active because they were trying to, in internet companies because they had seen what was possible with the internet.

And so a friend of mine, Aymeric Renard, who's still a VC at angel investor for many years in Silicon valley.

But I first met him in the '90s because France Telecom had sent him to go and say, "Hey, go and invest in internet startups because we know about where all this stuff could lead."

And by the way, I do want to say actually I'd just discovered this earlier today, which was going and talking about again, the, this MIT platform studies series, they actually do have a book on Minitel.

I've not read it, but if it's as good as many of their other books in the series, I'm going to pick up a copy of it.

And that'll probably be my reading over the weekend.

Grant: Oh, that's funny. Oh yeah. So there it is.

Ed: Yeah.

Grant: I mean, and so the idea here, I'm looking at this platform studies page, this is super cool.

This is them reviewing all these different pieces.

And so I mean, things you told me about Minitel, like there was businesses that were started that were like Minitel businesses, right?

Ed: Yep.

Grant: It was basically what happens if everybody in the country is online, and can... It's all connected.

Seeing that experiment run once before, it gives you some--

To that point of France Telecom investing in internet companies, gives them some foresight into what's possible when it actually rolls out worldwide.

Ed: Yeah. I think that it was really interesting that the telco companies were obviously the first companies that were able to go and see building a business on network effects of that nature.

And the amount of innovation that they did it's a shame that they didn't navigate the transition into the internet age, the given that they ran so many experiments, things like Minitel.

But even I'm not sure if I've told you this story, but my dad was at Bell Labs and his technical contribution was that he built the digital repeater circuits that were part of DSL, and ISDN, and all of this stuff and--

Grant: Oh, wow.

Ed: Yeah. And even at the time that they were building it, they had these ideas of things like video calls and all of this stuff that of course they never realized on the phone system, but now that's literally what we're doing today as we record this we're like--

Grant: Sure. Yeah. Yeah.

Ed: But the part about the future not being evenly distributed is definitely a truism.

Grant: Yeah. No, it's really interesting.

It's very true in enterprise software too where we talk about different companies that have the patterns, yes.

Back to our regularly scheduled program here.

Ed: Exactly.

Grant: This is just another random sort of question though is, and I'm guessing you've done enterprise software long enough.

How do you think about deprecating products or features, or as a product leader you're like, "Hey for example, we have some STKs that were like, these things have been around for a while. There's a handful of customers still using them. We need to get them to the newest SDK."

What's the best practices or what are the things that don't work when you're trying to get them over the line?

And how do you keep that? Because it's hard to transition folks too many times before they're like, "Hey, why did you leave me on the old system? Put me on the new thing."

Ed: Yeah. So first thing I would say is that I'd give very different answers depending on where you are in your business.

If your company is less than two years old, and you've still got a small set of customers and depending on where you are, if those two customers are giant companies and you're making...

Even going back to saying like, let's suppose you are making 10 million, but let's say it's less than 10 companies.

You actually should just go and literally do whatever is necessary.

Show up at their place, and install the new stuff, and just do the upgrade for them.

You don't want to be locked in.

And to that degree, you should just be like, "I'll do whatever's necessary. Look, I as a startup founder, I will spend my investors money to essentially go and do everything that's necessary to upgrade your systems. I will put people at your location. We will do it."

Grant: Sure.

Ed: We do not... And the reason why I say that is because it's not going to get easier later. Because guess what?

You won't have that option when you're at like the 50 to 100 stage, those customers, you will be carrying them on whatever version they're on forever.

Grant: Why is that different? Why is that just because contracts say that? What's the reason?

Ed: Yeah. Because they'll never be a good time to...

The contracts, you'll be at the point, not just the contracts, but you'll have, by the time you're getting to your 50 to a 100 revenue, it isn't a handful of customers.

It's going to be 50 customers, at least.

Grant: Yeah.

Ed: And that's assuming you did a really good job and you were getting the proverbial million dollar deals.

The reality is if you're doing to 50 to 100, you probably are operating on a base of at least 200 customers. Right?

Grant: Mm-hmm.

Ed: And so there's no way you're going to do a mass migration of 200 customers.

And I've been through this several times, this is where you're getting to your proverbial 2.0 to 3.0 upgrades.

Grant: Sure. Yeah.

Ed: And guess what? You'll be going and saying like, "For what economic benefit am I going to go and traumatize those people?"

You could actually just, you'll start to go and say, "You know what? It is probably better for me your engineering work at this point is at the point where it's like 50 people as well."

You're at the point where you're going, it's like, it'd be better to just have five engineers off in the corner whose job it is to maintain that thing than it is to go and create an upgrade nightmare.

And it keeps getting worse from there. That's where you will get there eventually.

You just don't want to get there too soon.

Grant: Interesting. Okay.

Ed: And honestly, this is what when you get into...

Going back to that point that I was making, like when I was talking about that enterprise company that I did know 22 years ago, there are people who are currently for the software that we did at Epicentric, that went to Vignette that went to OpenText.

There are companies that are renewing their ELA with OpenText today.

On the software that I built 20 years ago.

And it's being updated for the latest Java versions and all of that.

And the people are getting value out of it.

And there's nothing wrong with that. That's great. That's a different business though.

And every enterprise company though grows up to do that.

Like Oracle has products on their price list from companies that they acquired from other companies where they are maintaining it.

And if the customer wants to upgrade, they'll help the customer. If the customer wants to move to a new platform, they'll do those things.

But it is actually a sign of successful enterprise software.

If you've done your job right, Grant, there will be somebody 20 years from now that is using Replicated, whatever your current version that you ship this year, they'll be using that.

Grant: Well, that's the version. That's going to be the best forever anyway.

Ed: They'll be the best forever. Right. Right.

No, no I'm saying is like, they'll be somebody who's using it for something and they'll be paying top dollar to do it.

Grant: A million bucks. Yeah, exactly. Yeah.

Ed: They'll be doing it. And who knows?

This will be replicated, we'll have gone and done its IPO and it'll been acquired by Microsoft. And it'll--

Grant: You mean we'll have acquired Microsoft?

Ed: Yeah. You'll be, you've acquired Microsoft and so on.

And "Yeah, no, I like that. That's good."

But I'm saying 20 years for now, that's part of what enterprise value means.

That's a feature, not a bug.

That said you don't want to get into the situation where you are getting into the carrying costs of legacy until your companies at the point where you are mature enough to be able to, first of all, you want to make sure that the value the customer's getting, you don't want to be doing legacy carry costs for sort of small projects where somebody is paying you 10 K a year. Right?

But when you get to the pointsome total of that is a hundred million dollar a year business, then yeah. you'll be carrying it forever.

Grant: Yeah.

Ed: I've lived long enough where I've seen all, seen that full life cycle where you do get to that.

And it's a very different, maybe some of the people, folks listening in are at that stage, or maybe they're working on some of those projects and they're like, "Oh my God, I wish I could get people off of that stuff."

But no, I mean, it's a business in and of itself.

You just don't want your early stage startup to be about servicing that business prematurely.

Grant: Right. I mean, the challenge for early stage startups is when you're actually in the beginning, trying to find true product market fit, you might iterate a couple times.

We iterated several times in the SDK before we had true product market fit with the product we released two years ago called COTS.

And so the SDKs prior to that, one you don't know that you have real product market fit until maybe a year after the product's been live, so maybe it's...

Because that's when you're like, "Okay, this has been super scalable. This is actually where we're going, because what you don't want to do is prematurely migrate all of your customers to each of your iterative attempts."

Yep. If the iteration between one and product market fit, there's three different versions.

And people are happily using product one, like the three iterations between...

You don't want to try to pull them along to every new, every new version every time.

And so I think that's a risk because unless this is where we're really investing, because this is where we have product market fit, then you're prematurely pulling people into experiment.

You might pull one or two customers in, or maybe a new customer in, but you're not going to try to pull all of your customers in and maybe even your most valuable customers, at least that's what we did at Replicated.

And so now I look at where we're at and I'm like, "Okay, now we got a couple customers still on this older SDK and this older SDK, and I need to get rid of a couple of them."

And so that's my-- I'm trying to feel well, which one? How do I?

What do I do to not screw this up and not-- Because ultimately to your point, one of the key things about enterprise software, it's trust it's relationships. Right?

Ed: Yes.

Grant: And what you're doing is, you're creating a partnership and you're saying, "Look, we're going to be here to make sure you're successful with this."

And so I got an email from a vendor that we worked with and they were like, "Oh, we're changing your pricing in a month to be 10X, what it was."

And I was like, "Well, like that's not a good practice either." They have to have a mix.

You have to be like, "Hey, we're going to support what you need. We're going to transition you in the right direction."

Because we want you to trust us for the next 10 years, we want you to trust us and say, "Look, these folks have been on our side whenever we've needed update, when the market's updated, they figured it out and there are the folks that we trust to help solve this problem for us in an ongoing fashion."

Ed: I think that's absolutely right.

I think that the biggest challenge is, and again, this is one of these ones where the founder CEO feels this very acutely.

And even just the CEO, this is where it sits on the CEO, which is that, that you have this realization that all business value, unfortunately comes from the things that don't scale and may not be sustainable.

And your job is to like... Or let me say, all business value is created right at that edge.

And you cross edge at your peril. And so from an engineering standpoint, unless you're in product standpoint, you're always like, "Oh, well, that won't scale."

And you're like, yeah, but it's right at that point where you are actually getting to the point where the customer, where the most value to the customer is.

And so, yeah. SDK's are perennially the one that always is painful drivers, things like that.

Because going back to what we talked about from a platform and an ecosystem strategy, it's like, the first thing it's like, "Oh no, you got to meet your developers and users where they are. I need an SDK for that platform. I need this and that."

You're building your interfaces. And at your sort of ramp up stage, those are--

You're like, "What can I do? What can I do to get product market fit faster? What more? Oh, I need an SDK for that language or that operating system. Let's do it."

And then you rack these up. And at the same time, you're like racking up the costs of sustainability, like okay.

Grant: Yeah. And being able to move fast enough.

And just, I mean, for us, it's honestly the, it's our docs get so messy.

We literally launch a new doc site.

And we're like, "What do we do with all these old docs? These things that are supporting these other SDKs?"

And that's messy in itself.

If you talk about how important that is, it's like, "Well, you need to figure out the right way to clean it up or else people get confused, new customers get confused and start looking at the old docs."

And you're like, "Well, no, no, that's the old thing before the thing that you're using."

Ed: Right. For example, in our business, we've got the drivers that people use to talk to Cassandra.

And in the early days of DataStax, like having these drivers was a competitive advantage, it on ramped people.

Well, I mean, it's just, that it was actually just a business driver, like, "Oh people are using Java, let's have a Java driver. People are using Ruby, let's have a Ruby driver."

And all these languages. And we'd build a bunch of these drivers.

Every one of those drivers represents a commitment, like at the time we... I joined DataStax two years ago, but 10 years ago it was not the wrong answer to go.

If you were running the product strategy, you'd be like, "We need more drivers."

10 years later, you're like, "Oh, this is a sustainability nightmare."

And so then you go and say, "Okay, what can we do to consolidate these?"

And we go and say, "Oh, well, maybe if we build on top of GRPC, that we can eliminate the new need for language specific drivers."

But the technology isn't exactly perfect for doing that.

And you've got a lot of people who have baked in these drivers.

And so you're like, "Okay, how do you manage your investment around that?"

And it's not an easy answer. Part of being an enterprise business though is, people have bought in for the fact that they've said, "I'm going to choose this vendor who is committed to supporting these things."

And so you have to do the right thing by that, that's the relationship angle.

Grant: Yeah. It's very true. All right, Ed, well, I think that probably wraps it up.

Is there anything else you want to chime in before we end it here?

Ed: No. I think this was a great conversation.

I think that hopefully for folks listening, this is really the essence of what goes into product strategy.

Just all the stuff that we grapple with.

Grant: Yeah, yeah. No, this is really amazing.

This is again, you and I have talked many, many times, and this was just trying to get that out to the public so folks can hear how we think about products and different problems.

And I always love just bringing things up that I'm thinking about out.

So thanks for tackling some of those with me as well.

Ed: Awesome. Always pleasure. Look forward to doing it again sometime.

Grant: Yeah. And one more. Where can people find you online? What's the best way?

Ed: I'm on Twitter, but most of the stuff I do these days is on the DataStax blog and things along those lines.

Grant: Great. All right, look, we look for it enough there.

Ed: Cool.

Grant: Thanks Ed.

Ed: Take care.