Ep. #6, Enterprise Innovation with Andrew Peterson of Signal Sciences

Grant Miller: Hey, Andrew. Thanks for joining us.

Andrew Peterson: Really great to be here, Grant.

Grant: Cool. Let's just jump right in.

Andrew: Before we start, I was told that there would be beer here when we were doing the recording.

Grant: Right. I'll hail the waiter to come bring us a few. Just a second.

Andrew: That'll be afterwards.

Grant: Cool. So, let's jump in. Tell me a little bit about your background. Where are you now, what have you been up to?

Andrew: I co-founded a company, I'm the CEO of Signal Sciences and we're based down here in the LA area along with your company, Replicated. We're a cyber security company that does protection of web applications, web APIs, micro services--basically any type of web service that you're running--to be able to give people monitoring into attacks, or real time attacks that are happening on their applications, and then provide protection against those attacks in the same process.

Grant: Cool. How did you get into that?

Andrew: Yeah, right? Who grows up being like, "I'm going to be a security professional." I got roped in by my two co-founders. I worked with them at a previous job, we were all at a company called Etsy, and they've been doing security and securing engineering for ages and ages.

I was just a lowly product manager there, but ended up running a large business unit over time when I was there. While we were all there we overlapped on a bunch of different product projects, specifically around both fraud and security features, but we were all in the same very core team for a couple of months and then we just knew each other for a long time.

Grant: Cool, but Etsy's not really an enterprise software company, so what got you into the enterprise software world?

Andrew: The back story there is, a lot of people know Etsy from a consumer-brand standpoint. It's a publicly traded company now, it does $4 billion dollars in transactions a year. It's a pretty large scale site at this point, but it was about nine years ago that we were starting there, and the story that people may or may not know on the technology side is that they were some of the pioneers of DevO ps. They were doing a lot of things there before it was even called that.

They open sourced a bunch of tools, like StatsD is one of the things that they ended up open sourcing back in the day. They did a lot of innovation work around CICD pipeline stuff, that was on the software development side. Then as we were starting to build up our security team and build our secure presence there, what we ran into is that because we were doing so many things that were at the time very niche from a technology perspective, we ended up having a really big "Build, not buy," culture when we were there. That really started to--

We did that across the organization in a lot of different types of technologies. But from a security perspective, we built a bunch of stuff in-house because the stuff that was off the shelf, it didn't work. So we got the opportunity to be able to learn a ton of lessons at Etsy in this, what at the time, was a very odd and very unique kind of technology setup that a couple of years later we started to see the writing on the wall.

We would give talks to the industry about some of the things that we were doing and learning there to try to give people an idea about how they could do this stuff themselves, and everybody came back to us, and we said "We don't have 15 security engineers to build anything. We don't even have a single security engineer to build anything. How do we buy this stuff off the shelf?"

You start really understanding that when you get out of these high tech and forward thinking technology groups that end up doing a lot of this in-house development and creative software development for all sorts of things, including engineering tools. You get to the mainstream and they don't have that, and they have budgets and they have money to be able to buy this stuff, so there was a combo light that turned on for us.

One was that there was a real need that our peers in the industry were asking us for help on, and that just so happens to translate into a pretty big business opportunity as well. I think we heard enough feedback from folks saying they want help with this that we said, "Let's go help solve this problem for the industry."

Grant: Cool. It's as if there was this seed of change that was happening and Etsy was part of that original DevOps movement, and doing things very differently. The existing tooling for "How do you secure a continuously deployed application?" it just didn't exist in the market. So you guys were out there talking about that. Your co-founder Zane was the CISO from Etsy, and he was talking about how you're doing security in this continuous delivery world, right?

Andrew: Correct.

Grant: Then that created this demand and you felt the pull, is that right?

Andrew: Yes, it was a bit of a pull. I don't think any of us are sitting there being like, "We're geniuses and we came up with this. We're the first ones to think of this." You're just excited that you're learning some lessons on the job while you're building some of this tooling and you're excited to share it with other folks, but assuming that other people have this stuff also.

You're like, "We're not terribly special," but the more and more conversations that we have with folks, we're just like "There's really a core element here of, people do not have visibility into what's happening in a production environment from an attacker perspective." Again, this is something you just take for granted when you look back at it. I think we had this great backdrop of all the DevOps tooling pieces that we were building there, and really-- This is an interesting side story in some ways. But the efforts around what created DevOps, or what we were leaning into there, really just started from a "We want the dev team and the operations teams to work better together."

It was about cooperation, it wasn't really about a toolset or a philosophy, it was a culture thing. That's how it started.

What came out from that was these lessons learned of being like, "If you're going to make tools to be able to enable some of this cultural shift, or enable these teams to work together, they have to be super easy to use and they have to be useful for both sides of the house." I think as we started to think about security and how to integrate security into that preexisting culture and philosophy that we already had at Etsy, that again was very unique at the time but seemed normal to us because we were just in it, we were thinking the same way about security.

So now people call that DevSecOps, or SecOps or whatever. It has like some nomenclature that goes along with it. But that was just such a core part of our DNA that we were like, "When we're thinking about security, how are we going to think about solving these problems for runtime, or production applications? What's important there?" "We should maybe get some monitoring there to even understand where the problems are that exists in the first place."

It was just such a natural thing for us to think about. The rest of the industry was all based on a waterfall model of application delivery where the dev team builds the code, they pass it off to the next team, and the next team, and the next team. Security is just one of those teams in line in the waterfall, and then when a security team gets it they solve all the problems, they fix all the bugs in production, and then when it actually goes to production and you're assuming that it's safe.

You never really thought about, "How do we get a feedback loop from the behavior of the people that are using my application back into my dev cycle?" To be able to actually make those adjustments. We learned those things on the operational and on the development side, and we really applied that same learning to the security side.

Grant: So how did the company start out of this? One, I think it's interesting to just say I've seen this pattern of a great team inside of a company doing a lot of new things, sort of recognizes that there's this opportunity that the market will more likely come towards them. You see, like a lot of times people at Google, launching different-- "We're going to bring the way that Google does X, Y or Z to everyone else." You did the same thing, "We're going to bring the way that Etsy's been doing security to everyone else because this is known for continuous delivery."

That's a great founding story. It really helps to sell the message. Plus the other thing that I know about Signal Sciences is that you've told me that Zane's early videos and talks about security in DevOps have been like this huge flag in the world that you guys planted around how to do security in the modern age, and that brings people to you. Was all of that happening before you started the company? When did that really come together?

Andrew: Yeah. Giving talks in the security world is a very common thing that you do. There's lots of different security conferences and stuff that are out there, so I think "How do you make notoriety for yourself?" In the industry it really comes through doing talks, and I think both Zane and Nick have given talks in the industry for a long time. They're just unique in the sense that they're really good communicators, they're not only brilliant in terms of how they think about things, they're very humble also, but they're funny. They're entertaining.

That I think was certainly the key to be able to get feedback from people. Sure, we have followers. A lot of people are looking at these videos, but I think even seeing the sheer number of views and the sheer number of feedback that we would get, we just saw that it was really resonating that this was a problem that was clearly not well solved, if there was a solution to it in the first place, and clearly continue to be growing. Because we are obviously not like, again, we're not the smartest people in the world. I think we just got lucky to be in the right place at the right time, to be able to get that experience at Etsy, and then really hit a chord of a line of conversation around the stuff that a lot of other people were going through at the same time.

Grant: Then you started the company. So, what did that look like? What got you out of the door and into building something for yourself and making this a product?

Andrew: As a lot of founding teams do, we spent a little bit of time upfront just making sure that "Is this something that's legit?" For a lot of us that start companies, especially if you're starting them out of a successful career that you've had at other large technology companies, the allure of staying at those companies is quite large. We're in a very unique time where our skills are highly sought after, and so if you want to go work at a larger technology company you can be highly rewarded and highly compensated to be able to do so.

I tell people a lot, and I still actually believe this, that probably one of the most important things for the company was just getting all of us to agree to quit and start the company together.

It's really hard to make that decision yourself, to feel like you're making a big risk in starting a company, and there's lots of different risks that that goes into that. Both personal risk and financial risk. But doing that across three different people who are bringing both unique and really incredibly important skill sets to the table, to be able to get something off the ground, it's quite hard.

The good news is because we had experience working together in the past, we didn't have those questions. Like the questions of, "How would we work well together?" And "What roles are we going to take on?" We had those conversations very early on, but it was pretty easy to define. The bigger question was just like, "Are you willing to take the personal and financial risk to start a company?"

Grant: And then once you did start, you really went enterprise from day zero. You didn't try to offer this to SMBs or do something open source, you really went straight ahead for enterprise software companies as your earliest customers. Talk about what that was like.

Andrew: We were in a pretty unique situation. Again, now, especially looking in hindsight and having talked to a lot of other and worked with a lot of other startups in the space. We were in a unique position because we had built a lot of these techniques and learned a lot of lessons while we were at Etsy, and went out to the market and actually gave talks about these things and gotten a lot of feedback from people. They're like, "Yes. I need that that exact functionality."

We didn't have to start the company being like "We should build an MVP to see if it gets used, and we should do--" We took venture capital money from the beginning. There's a whole line of conversation that would be interesting there, but probably for another time. We took that money from the beginning because we really wanted to try to grow something really large. We took that money from the beginning, we hired people, we really spent the first probably year and a half to two years just building out the technology.

We tried to get users and stuff along the way to be able to help give us feedback, but we were really building for ourselves. We knew what we needed. It was basically this super next generation version of the hacky stuff that we built in-house when we were at Etsy. We've almost had a roadmap for three or four years from our first four years of what we wanted to build, so in some ways we're just now getting to the point where we're like "Let's start to figure out what we do next," because we had that vision.

But the value of what that meant is that in our first 20 customers we got to have one of the biggest banks in the world be one of our customers, because we were really familiar with what was required. Not only from the functional perspective, but from "What do you need on the security side of this?" and also what some of those requirements were to be able to actually sell a product into a larger enterprise.

Grant: How did you know what those features were that you needed to sell into large enterprise? What was the--?

Andrew: There's a combination of things there. One, Nick and Zane my co-founders, they were both big security vendor buyers when we were in-house at Etsy in the first place. They had a lot of personal experience with understanding what's on a security questionnaire, "How do you need to architect your technology to make it so that you get past some of those things?" We were running a cloud service so we knew that privacy was going to be a huge issue. Privacy and performance.

It's interesting that the GDPR is coming up now, we don't-- We actually haven't had huge issues with GDPR because we built a privacy model in from the very beginning, because that was actually going to be a really key component to being able to successfully sell to large enterprises with it, with a SaaS or a cloud backend service that we were providing. Some of it was that, some of it was actually having experience.

My co-founder Nick and I, we actually developed basically a version of Zendesk in-house when we were at Etsy. We had this whole "Build, not buy" culture there. We were like, "Of course we can go and build our own customer service platform," and it turns out we went through all sorts of-- You have role based access control, you have to have logging and reporting on that to understand who made what changes, to be able to-- So we actually had some pretty hands on experience actually building the product there to know those pieces.

I think the combination of both being a buyer of security products for many years on one side, and then also building and producing basically enterprise tools in-house when we were at Etsy, and I've done that at previous jobs also, gave us a really good starting point. Then afterwards, that's when you listen to your customers pretty quickly. You can have as many of those conversations upfront as possible, but you learn along the way.

Grant: So, you're building yourselves and I think you had a lot of other security vendors as early customers as well, right? Was that just using your network, and talking to the people about how they were doing it, and showing them what you had? How did you get those very early customers?

Andrew: This is one of the things that's a tough thing about building something that's actually truly innovative. Not to pat ourselves on the back, but it actually does come with challenges.

If you're innovating a space, where is the demand? If the product doesn't exist right now, then it doesn't exist for a reason. People aren't thinking about asking for this.

A lot of what people affectionately call "Evangelistic sales," or something like that, is that you're really having to go and find the people that have a vision for what it is that they want from a product that's in the space and try to match up with those people. The challenge there is you want to be innovative, but also somewhat familiar. We've had a lot of challenges with that over the course of launching the product and then iterating our product positioning over time, where I think initially we were so focused on being like "I don't want any competition. We want to have the product that nobody else can do, and we're the only ones that can do it." I look back on that like, "That's cute. That's so naive in some ways."

Now when I'm working with other folks that are coming up, it's actually a really strong thing if there's other competitors that are in the space and you need to find your way to be able to sort of differentiate yourself from those other players, but if they're already there and there's a pre-existing market that means it's a foot in the door being able to have some of these sales conversations.

I think one of our biggest challenges early on was just figuring out how to market our technology in a way that was actually consumable by people that did not have the same future vision or experience that we had when we were at Etsy to know what they should need.

Grant: There's often a lot of context that's required in order for people to understand what the innovative thing is you're talking about. Because if they don't understand continuous delivery, or deployment, whatever you want to say CCD is, then they're not going to understand why they would need a solution in the security space to solve that problem.

Andrew: Yeah, exactly. A part of it is like, "Where do we have to begin? What are the selling points--we used to think that was going to be the big selling point. Where like "Are you leaning into dev ops practices? If you are, it creates these inherent problems with the technology that you're going to run into. The existing tool that you're using right now to try to attempt to do what we're doing now. I f you are, then this is why we're the perfect one."

We thought that was going to be a killer way to have those conversations. Turns out some people did that, some people didn't. Some people were leaning into those things, some people weren't. Those have become much more standard practices across any type of large enterprise, but even today, we don't go into large enterprises being like "Cool. You guys are doing CICD so you need this tool." Sometimes they don't even know what CICD is.

I think the bigger lesson learned for us is that you need to learn, what are the pain points that they're thinking about today that they will be able to buy today? Some of these folks might like having conversations about the future of what problems you can solve for them. And this is like for us, the example would be "Sure. If you're moving to a CICD pipeline where you're changing your application on a very regular basis, then you can't use a waterfall model of development. You have no time to be able to look for bugs before they go into production, so therefore you have to have some type of understanding of where attacks are happening in your production systems because your app is changing so often."

It turns out that same thing, if your app is not changing at all, you still want to know where attackers are attacking your system in any part of your system because you've never had that visibility before, so at least you know what the problem is that could exist. We evolved it back into that, and then we had to take a step even further back in the future as we evolve to saying "The technology you're using today is called a web application firewall. We do that better in these three ways, including cost savings. And these--"

For us it was important when we were getting off the ground to be able to sell to people that did have this vision for the future, because they were the only ones that were going to take a chance on a brand new vendor like us. We found that people that really matched the vision that we had so we didn't have to have these super in-depth conversations. But as you move up and crossing the chasm, or whatever you want to call it, you move into the mainstream. You're just not going to get people that are sitting there with a vision of what their products should be doing.

You got to find a way to sell more to the pain that's important to them, which could be "How do you make my job easier? How do you make it so that I don't have to spend as much money on this stuff?" Or, "How do you alleviate political issues and stuff that I have internally?"

Grant: If I break that down it's sort of like when you first came out with your product there was a platform shift, a paradigm shift, which was continuous-- CICD. That concept, you thought would propel the market and adoption of your product, and it did for maybe your first few customers. They were like "Yeah, we love continuous integration. Of course we need something, a new security tool, to solve that problem." And then you ran into the end of that market.

We've had those conversations, but now people don't really understand that, or we don't want to wait for them to be totally CICD'd up before they're going to adopt our solution. Now we need to be able to, maybe not even change a product, but at least change the description to retrofit it back to how they're doing things today and compare it to their current solutions, and say "Even in a world of waterfall deployment, you still need this tool."

Andrew: This is something that I talked to folks a lot about. I might have talked about this stuff in the past. When you're getting off the ground you don't have a brand, you're trying to go to people and have these conversations to convince them that they need your product, and most of the time they're just looking for an excuse to either get off the phone or just derail whatever it is that you're selling.

They'll throw up a bunch of these either false roadblocks, where you can't even actually get to the value conversation there around, "Cool. Do you need visibility into the attacks that are happening on your website?" And they're like, "Do you have SAML? Do you have role based access control?" And like at the beginning we're product people, so we're like "No. We don't." It was very matter of fact, like you either have it or not. It's like a binary. "No, we don't have that yet. It's on our roadmap." Everybody's heard "It's on our roadmap." Like, "On our roadmap" means "No it's not in the product." But the problem with that is that it would stymie us from being able to have a deeper conversation around some of the problems that we could solve for them. They just derailed it by saying "Do you have these things?"

One of things I've told other people before is you've got to identify some of those red herring type of questions that people are asking. It's basically like these questions that are just trying to create a roadblock for the conversation so that you can't actually get into the meat of something, where maybe you can actually learn from them about what their actual real problem is.

When they bring some of these things up that are really core features of being able to sell to the enterprise. The thing is, it's going to take three to six to nine months to sell to these folks in the first place, so we've learned that we could move so fast by building those things in if that really was a requirement for them. We ended up starting to just say, "Yeah. We've got SAML. If that's important to you, of course we got that. Let's move on to the next question, or the next thing that you're trying to decipher whether or not this thing is valuable for you."

That'll change over time as you start building your reputation. People actually have already heard about you and they've heard good things, and then they expected you have that stuff already and they're not looking to just challenge you. I don't know if this really is answering your question specifically, but it's something that I think is really important for people that as they are starting to sell into the enterprise, that there's going to be a lot of pushback and requests and stuff that you're going to get from those folks on all sorts of different types of technology things that you wouldn't have thought that are necessary to sell in to those people.

But really, the goal of your conversations should be to try to get them to the point of saying "Is this something that's actually valuable? Would you pay for this thing?" Don't let them asking you sort of these side questions, "Do you have this setup or this technology?" To get in the way of that. I would say don't be afraid to just say that you have those things to be able to continue to try to progress in the conversation.

Grant: Part of that, from your perspective, is because specifically for Signal Sciences you're really only selling to enterprises. Your roadmap was like, "We need understand the functional value of our product, make sure we're communicating that correctly," and then you were committed internally to build whatever ancillary features were needed for enterprise adoption. You just knew that you would have plenty of time between someone describing all the problems they have from a functional perspective, between them actually signing a PO and implementing it. So you knew you could hustle and build those pieces.

Andrew: Yeah. Those things might not even have been things that they really required, like if they got to the thing where they were like "I really want that value," they might not actually require it. I use this example a lot, it's like this just gets down into compliance standards and stuff that people have. Where they sometimes say, "Are you SOC 2 compliant? If you're not we can't ever work with you."

They would be hard pressed to be able to have a list of vendors that they use that all of them are SOC 2 compliant today. I can guarantee you, I know multiple publicly traded security companies who are not SOC 2 compliant. It's really more that they're using that as a means of derailing the conversation so that they don't even have to test it. In some ways it's not so much even that "We don't have SAML, we're going to have to build that over the next six months before we actually sell this to them."It's more that they're asking you that to stop the conversation, so you say "Yes," and then you just continue to proceed down having a conversation with those folks.

Because one of the things we learned that a lot of the conversations here for product and technology minded people like us, you're just like "This value is so undeniable. Why can't you just get it, and then cool, we'll have a transaction and you pay this thing, we'll charge a fair price for you to use it, and then you buy--" That's not how the world works in general. It takes a while for technology people to really understand that, but then the flip side of this is basically saying again "What is the value that we're offering? Is that value something that you actually care about?" And then, "What are the processes that we actually have to go through to be able to get that technology in place with them?"

To add on top of that, we learned that a lot of the goal of our first conversations with any of our customers, it's not to get them to use the technology. It's just about getting the next meeting. "We had the first meeting," the goal is to get the next meeting. Because when you're selling to a large bank you know that you're not going to have one meeting and they're going to make a decision. You're in it for eight months until they make a decision there. So, the goal is always "Get to the next meeting, get the next step. Make sure that they're interested enough to continue to have a conversation."

Grant: Is part of the decision making criteria, they do a proof of concept? A POC?

Andrew: With our technology, yes. They do.

Grant: OK. So that's part of every deal, a POC is done before--?

Andrew: Yeah. It's actually becoming less and less now, it's still the majority of them and really because it's easy to use, the product is easy to use so it's easy to actually get installed. We've had a couple of contracts where people actually buy it sight unseen, which we see as a real maturity step for us. Either we have a good enough brand already, or good enough customer references, or whatever. But early on you've got to put your money where your mouth is if you're saying something, because again, you're sort of guilty until proven innocent type of thing when you're going in to actually sell. Especially to enterprises.

Grant: Then you just tell them that the SAML integration is not part of the POC. They have to sign the enterprise contract to get that feature toggled on.

Andrew: Something like that. You've got to be creative as you're building your business. You can't build every single feature from the very beginning.

Grant: But you did say that you architected from the beginning understanding that you would be building things like role based access control, and single sign on, and reporting, and all these other features that we sort of think about as enterprise ready requirements. Right?

Andrew: Yeah. That gets back to our experience of having bought these security products before for larger enterprise that we were working in, and having to develop some of these things ourselves. Where like, one side of the architecture was building for scale, we were able to do that really well. Kudos to Nick our CTO who is fantastic at being able to do this, because he's had a lot of experience building out scaled systems which is-- That's the engineering side of the house, but this is really a product feature question, which is "Are you architecting your database to have multiple different roles, and then being able to match those roles with different types of access and product functionality?"

We did that stuff from day one. Really, day zero. When you're thinking about just how the models are actually built in the first place, so we didn't have to wait to the point where we went to ask a bank and they were like "We need some people with read access and some people with write access." We're like, "Yeah. We know. Got it."

Grant: It helps to just even have the knowledge about those features before you go into those conversations, because you look like you know what you're talking about.

Andrew: Not only that, like we'd go in and they'd be like "Do you guys have admins and users?" And we'd be like, "Actually we have even another role that is a read-only role, so that you could add other people to the platform that was actually dealing with blocking production traffic, and you don't want to give everybody access to being able to block your production traffic."We actually used a unique role in role based access control as a selling point into them. It showed this depth of maturity into our understanding of how to build a product for their needs.

Grant: I think that communicates a lot early on to enterprises, especially number one, you're only going to market to enterprises so that's all your customer references are and that's all the conversations are.

No one is looking at your site and seeing some tiny SMB using it, so everyone thinks it's enterprise ready from the get- go, and then probably also allows you to command a higher price in the beginning.

Andrew: This is a core part of the story, that if I know anybody that's gone through the same experience where they've been in-house and they've dealt with those experiences and they're building a product that comes out of that experience of building stuff in-house, or at least getting even access to the problems in-house, lean on that heavily in your sales conversations and your marketing conversations.

Because it was so important for us to be able to go to these folks and say "Yeah, we're a vendor. Yeah, there's this natural adversarial relationship in some ways between "You're the buyer and I'm the seller" type of thing. But we were on your other side for ages, so we know your problems so well, that we've created a solution that is exactly how you would have designed it from the beginning."

The way that we sold that at the beginning to our first customers, we were like "When you come on you'll be able to get access to adjusting the product roadmap in the future," when in reality we didn't actually have to adjust the product roadmap very much at all because we already knew the problems that they were getting. But if people needed to hear that to be able to get excited about getting on board, of course we'd sell that.

But the reality is if you do have that story, if you do have that experience, you have such a huge leg up on anybody else that's trying to do this because you have personal experiences. You're developing for a very practical solution to the problem, instead of a theoretical one, and that is just an absolute game changing conversation that you can have with the customer.

Grant: You said you were building for yourselves, because you were basically building the version of what you would hack together at Etsy. You were building the next generation on steroids version that you'd want to use yourselves.

Andrew: Yeah, and that was agnostic to the platform that you were solving. So much of the in-house stuff that gets built that's a hack day project or something like that, it's built for one monolithic platform, or one specific type of customer. So it's a very different thing to build something that's really agnostic to somebody's platform.

Grant: Were you doing early product? were you doing early customer development? What was the roles that the three of you took? Then you said you hired pretty quickly, so what were the first roles you hired?

Andrew: We hired design and engineering, and then we hired some product and then we actually hired sales pretty early on. I think a lot of people that are-- Again, technologists tend to focus on like "If we just get the tech right, if you build it they will come." I'm not an "If you build it right they will come," type of technologist. The actual sales process, the political realities of selling into organizations, the relationship development piece of sales is almost just as important as the actual technology that you're selling. How many companies do you know today that have really not great technology that are really strong companies from a money perspective?

Grant: Salesforce.

Andrew: I'd say there's a lot. There's a lot of ways that you can succeed. If you have really good tech and you are investing early on in both sales and marketing, I think that you're giving yourself a real leg up on people that are only focused on building great technology. It's funny because my CTO, fantastic incredible technologist, also incredibly business savvy as well, he loves actually digging into sales stuff because he's like "There's actually a real methodology and there's a science behind sales and marketing as well that being a trained engineer I never thought that that these things existed." But if you hire the right salespeople that come along that are super nerdy about these things I think you can really systematize and work on building your sales motion as a product within your organization as well.

Grant: Early customers, first three, four or five customers, you Nick and Zane all three in the room? Like, pitching them and selling them? Or, what did it look like?

Andrew: No. Zane did a lot of that customer development stuff early on. This gets back to how Zane was the CISO at Etsy and he could really speak to, and continues to be, an incredible representative of our sales team, or an extension of our sales team, because of this very authentic story that we're able to tell, saying "We struggle with all these things. Do you struggle with those right now?" "Yes. We were so frustrated with this." "We went and solved it. Do you want these solutions too? We'd love to alleviate that pain that we both had going through this before," you can establish that sort of camaraderie there.

Plus he was the one giving a lot of talks externally while he was at Etsy, and Nick was too valuable to have. Like, we were building. We were just trying to keep up with a really long road map that we knew that we needed to build.

Grant: And you were--?

Andrew: I was involved in some of this stuff. I would be involved in a lot of these conversations but because I didn't come from a security background, a lot of what I was doing early on was listening, and then providing feedback. I'd be there with Zane a lot of times, he'd be the one doing the pitch, and then we'd come off and I'd be able to be like "This really resonated. This thing didn't." And be able to help start making some of those adjustments. It's really helpful to have two people in those conversations, because you might actually have a team of like 10 people on the other side if you're selling to an enterprise and if it's one on ten it's incredibly hard. Because they are just pounding you with questions.

So I'd be able to jump in with stuff over time as I was learning the lingo and learning how to speak security. But this is one of the things that we were very cautious about early on. I didn't want to jump in and do that, because literally there are words in these industries that if you say them you get outed as an outsider. Case in point, I started the podcast today saying that we're a cyber security company. Like, there's a joke about "cyber," the word "cyber." People on the outside would say that but people on the inside would never say "cyber." I say it now because it's a mainstream thing, like mainstream people call it cyber security. But if you're trying to sell to this early adopter that's really sensitive around these things, if I were to even say those things they'd be like "Oh my gosh, who is this guy talking to us?" They wouldn't take me seriously.

Grant: It's like if you call San Francisco "San Fran."

Andrew: Yeah.

Grant: Everyone knows.

Andrew: Or "Frisco."

Grant: Yeah, you're not from San Francisco. You call it "SF." I learned that one. That's funny.

Andrew: No, my role early on was to basically fill in the gaps for everything that they couldn't spend their time on. I built a bunch of back of house solutions, made sure that we had a ton of the rest of the path moving. I did a lot of the product management early on, making sure that we were on track, that things were well defined in terms of what we're actually building. Because that's a lot of what I did when I was at Etsy early on.

When it's three people or four people or five people, you do whatever is needed. Especially because early on you're trying to hire people that have very explicit experience and very explicit skills to crush what they're doing.

I'm not hiring a jack of all trades at the beginning to do those things, I just filled in the gaps for all the things that were not there. And made sure that we had money in the bank and continue to be able to have money in the bank in the future from investors, that's a big part of a job that a lot of people having built and managed technology teams in-house, it's a huge part of startups. I drastically underestimated how big of my role would be associated with making sure that we still had money in the bank. That was a big steep learning curve piece for me.

Grant: Chief fundraiser, right? One thing we were talking about earlier is how enterprise software has changed in the last 5-10 years. You were mentioning the importance of ease of use and how that plays into the professional services, I'd love to have you touch on that a little bit.

Andrew: I'll try not to talk too long here, because I have a lot of thoughts on this stuff, and it's been really interesting to see--

Grant: Go on.

Andrew: A couple of things early on, just like some practical learnings that we had: One is we started to sell professional services on top of the basic SaaS product that we sell pretty early on in our lifecycle. There is sort of a bunch of different reasons for that, but part of it was, again, big bank was one of our first 20 customers. Big bank expected a professional services agreement to come along with their product agreement, and they insisted on it. They said, "No you have to sell us this." And they sold it in hour increments.

We'd never sold services before, so we had to get up to speed on this stuff. We've learned over time, and there's a couple of things that are actually really interesting about this. I'll say one thing and I'll come back to this. The first piece is, again, just practical thing and practical knowledge. When large enterprises especially buy product technology, they have a separate budget for the technology as they do for the services, and for ages and ages and ages you always bought both the product and the services and they come from separate budgets and separate money pools.

If you're a new technology company and you're like us, you take a lot of pride in the fact that you don't need to have somebody handhold somebody through the process of getting up to speed using your technology. You want to make it as usable as possible, as scalable as possible, because why wouldn't you? But it turns out, as a result, you almost take pride in the fact that "No, we don't have professional services. You don't need to buy professional services. You can use it on your own." Then you're just leaving money on the table, and this is what we learned.

If we sold professional services along with the actual product we assume that if we sold professional services that's going to come out of the budget they have for the product, so we're going to have to sell it at a smaller ARR subscription model to do it. Nope, turns out they'll buy it for the exact same price. A lot of times, sometimes companies are shifting to a different model and it depends on how big they are, but really the large enterprises-- Nope. They're going to buy a bunch of ARR, model pricing, and then they're also going to buy a professional services piece.

So our question was, "Then what do we do with the professional services?" So much of professional services, historically, has been about. "How do you get it installed?" Having somebody come on site and take the magic pizza box that you just bought and install it into our network hardware. This is why, again, these are the fun pieces of selling into the enterprise. You start seeing on security questionnaires that you need to have a background check and a drug test on anybody that's going to come on site to be able to work in my company. You could just cross those things out completely, because it's the software guys, we're not coming on site. You guys install that and we'll give you directions for how to do this stuff.

Grant: It's California, we're not drug testing.

Andrew: Yeah, exactly. Thank God. What we learned is that in this new world of SaaS, a lot of times the professional services that we're selling now--A lot of the actual things that people are buying and the services that we're delivering are more colloquially known just as "Customer success." When we were starting the services org we just had this weird assumption that customer success was free. You offer customer success as a free service to these people, but you sell to these large enterprises and they're happy to pay for things like training and continuing education and some customizations and tips for how to customize a tool to get the most out of it, and quarterly check ins with the teams to make sure that they're getting the most out of the actual product.

Because guess what, they're buying multi-year contracts a lot of times anyway. So they're invested upfront and they absolutely have the same incentives as you do as making sure that they get the most value out of the product. Now, the corollary that's fantastic about that is that you end up getting much higher rates of retention, much higher expansion rates because you're getting people to actually get the full value out of the product, and you're doing great customer development at the same time. Again, you just get them to be able to actually pay for those services where the industry just has this weird model that you don't pay for services.

So, that's one line of feedback there and advice for people, is "Don't think that customer success has to be, or professional services don't have to be installation. It can be customer success, and customer success doesn't have to be free."

Grant: Martin Casado just went on a tweet storm fairly recently about how enterprise software can really be driven through professional services. The idea that he lays out is that you can use your services organization to drive new product adoption, and move people towards your way of thinking, and find new opportunities to expand. So as you get more and more integrated with that team you're able to introduce them to new technologies that you're delivering. It's kind of this hybrid.

Andrew: Yeah, Tomasz Tunguz from Redpoint has done some really interesting analysis on some of the big SaaS companies that have gone public in the last few years, and the breakdown between which ones have big services organizations and which ones don't, and trying to correlate that with retention and expansion. There's definitely some correlations there. I would highly recommend it. We've had a lot of success doing it.

The other thing that I just want to talk about in that space is, there's this interesting experience from, again, there's sort of native SaaS technology companies that are coming at this. We just bring a very different bias to this process than the folks that have been buying enterprise technology for a long time in large enterprises. And those folks, there's been this paradigm where if you don't have professional services and it's not hard to implement and it's not really complex and it doesn't require a lot of customization on it, then it's less valuable. The thing where if it's harder to use and it's harder to customize, it means it's way more valuable for you.

We really view like a core value of what makes a premium product, it's actually the opposite.

A premium product should be as easy to use as possible. I think that is just a mindset for people to think about a little bit. Really think about how you can up sell to your customer that actually not having to tune a bunch of stuff, or not having to customize a ton of stuff, or not having to spend ages installing it and buying a professional services contract just to get the thing installed and running. That's a deficiency, that's not a feature.

But you sit there and we have these conversations with customers, we say "Not only is this thing incredibly easy to use and your total cost of ownership from an FTE, how many full time employees you're going to have to actually run this thing, you don't have to have people actually running it. But it's also more valuable and more functional, and will do the actual function at a much higher accuracy rate," or something like that. They just don't believe that.

They basically say, "If I don't have to put that much time into it then there's no possible way that I can get more value out of it. This is just a down-market cheaper version of what I do." So, just be wary about that as a way that other people are interpreting when you're talking about "This thing is super easy to use," they might assume that it's also less valuable or less functional, or less effective than the thing that's harder to use.

Grant: Mark and I, my co-founder, talk about this in terms of trying to create a really easy to use experience. There's a lot going on underneath hood that it seems fairly easy from above, but you need to expose some of the depth of the product in dashboards and UI so that people can see even though it's simple, they should still see that there's a lot-- There's things happening. You want to expose some of the depth and make it so that it's like when you look at it visually, "Wow. This is valuable."

It doesn't mean that you need a complicated process, but it should still try to expose the value that you're creating and the information you have. That's this really important piece that I think is a balance, because you don't want make it too complex but you want to show people that you're bringing value.

Andrew: I'd say "Yes and no," I think it really depends on the product that you're building because if you are going into an existing market that has a really bad example of use of a product, or just execution of a product, and you just get the same function out of it but it's incredibly easy to use and super well designed. That can be enough. Where it doesn't need to be super complex, they can just be like, "The alternative is so bad and this is so much easier to use, even if I'm getting almost the exact same function I'll choose the one that's easier to use."

When you're going into a new field I think you're really up against that "Build or buy" culture where if you make it so easy to use then I think people think that it's either "Not that valuable," or "I could do it myself."

Grant: I've run into that a few times.

Andrew: Security is a little easier because it's a bit more of a niche-like engineering sub function that most people aren't presumptive enough to think that they can do it themselves. I think we've dodged that bullet a little bit ourselves, but I think most people are building, especially engineering technology, it's really hard to dodge that bullet.

Grant: I see your point. The security industry is doing a good job of telling everyone that you shouldn't build your own versions of these things, and if you do you're like-- If you've invented your own encryption methodology you're an idiot.

Andrew: It's taken us eight years to do what we're doing, so we're like "If you want to go down that road and try to do what we're doing, we'll give you pointers. We tried to do that."But I get what you're saying.

Grant: It's like, "The boogeyman is right behind you. So, be careful."

Andrew: We call that FUD. Fear, uncertainty and doubt.

Grant: It's like, "You can try."

Andrew: Yeah.

Grant: "Good luck."

Andrew: Yep.

Grant: Andrew, thank you so much. This was a blast. I really appreciate all your insights. I wish we had more hours to talk, but I know you got to run. We'll have you back on, I'm sure, sometime in the future.

Andrew: Happy to. I'm just down the street.