January 9, 2019
Accelerating Inside Sales & Account-Based Management
Whether you’re accelerating your inside sales, or just building out your first sales org, Heroku’s VP of Digital GTM Jason McClelland, a...
In this finale fireside chat, Auth0 CPO and former DigitalOcean SVP Products, Shiven Ramji, joined Adam Zimman, startup advisor with experience at companies like LaunchDarkly, GitHub, and VMware, for a conversation to wrap up all of the themes from DevGuild: Software-Defined Movements.
Read on to hear their community strategy stories and lessons, from developer community building at the early stage, to monetizing your product in the growth stage, to finally scaling from product to platform, all the while building a software-defined movement.
Adam Zimman: First off, wanted to say congratulations for the big news recently with regards to Auth0 and the acquisition by Okta. I think that that’s a pretty amazing outcome. Would love to also just quickly on that note, have you talk a little bit about something that I saw you do, that I thought was a really great way of being able to ensure some continuity with your community. And that was that you put out this blog post.
We’d love for you to talk about why you felt the need to put this out and why you made a point to actually go this extra mile.
Shiven Ramji: The context behind the post was really making sure that we address developer concerns. When the announcement hit, there were already some HackerNews posts that, “oh my god, I’m on the free tier with Auth0, they’re going to shut me down, they’re becoming an enterprise company.” So it was really to address that sentiment directly and just assuring our customers, specifically developers.
Because we do have a free tier and we have lots of developers, whether it’s for hobby projects or for early stage companies, they’re essentially using our platform. And so we wanted to make sure we address that head on. If you’re building developer products, this is fairly common. You want to be transparent, you want to be upfront, and you want to make sure that you address that community so that you can remove any anxiety. So that was the context behind it.
Adam: I like how you say that that’s fairly common. I would argue that it’s probably not common enough, but I hear you. I think that
that notion of transparency and that notion of trust and building trust, and the simple ability to follow through on commitments or promises that you make, it’s amazing how that one aspect really helps to define your community.
So I know we jumped right in but stepping back for folks that aren’t familiar with your background, prior to Auth0, you were at DigitalOcean for a while. Many of the folks that are going to be watching and participating in this event are probably familiar with DigitalOcean, as well as its developer community and the developer trust that they were able to build over the years.
And so I’d love to hear from you, having gone through that experience at DigitalOcean and seeing the impact it had on the developer community and the way in which independent developers could get up and running so quickly, any takeaways that you had or lessons your brought with you to Auth0? Lessons learned that you maybe did a little bit differently.
Shiven: So let’s start with DigitalOcean first, then I’ll share what was common and maybe what was different. I think they really focused, from the very early days, from the founding of the company, the founders focused on a specific audience that wasn’t addressed. AWS was leading the market, but they weren’t really addressing developers. DigitalOcean had developers, from students who were just starting out to people who were learning about DevOps, all the way to established companies.
Content was a big part of the DigitalOcean flywheel and it was all about helping developers be successful, whether it was launching a WordPress website or learning about containers. So content was really good. And it helped DigitalOcean build this really authentic community.
What I mean by that is , we were fairly active in our feedback forums, fairly active on support tickets, I was answering questions that customers or developers would post on social channels. So because we had this feedback loop for them, we really created this bottom-up following, if you will. DigitalOcean was a product-led growth company, and so it was all about how do you put up these products, get organic adoption, and then continue to grow from there. Community content was really key there.
Adam: One thing that I’d add to that is that it resonates with the previous conversation and something that Ed said, which I liked, it was, “Be opinionated, but don’t be selfish.” DigitalOcean did a phenomenal job at that, where the opinionated designs of being able to have those pre-built configurations was so amazing for developers, but at the same time, there was a willingness and the ability for developers to come in and construct their own stack if they needed to.
So there wasn’t that myopic perspective of, “No, this is the only way it can be done,” but it was like, “Hey, look, we’ve tried a bunch of stuff and we’re going to make it easy for you.”
Shiven: I’ll share a really funny story. We had a lot of developers who actually, even if they were building on Amazon, they were coming to consume content in DigitalOcean. It was fairly common. And so when we met the AWS devrel teams at conferences, they would come up to us and say, “Oh my God, we love your content.” So again, same concept of this idea of,
if you build authentic information, content or tools just to help developers, that goes a really long way in building a brand.
Adam: Absolutely. So as you transitioned into Auth0, I know you came when they were pretty far past the early community building. They had established community, but I think that you took on at a time where they were really looking to make sure they continue to balance that early adopter community and the freemium tier community and balance that with the enterprise. I’ve known folks at Auth0 for a long time, they’ve always had a perspective that they wanted to be an enterprise platform that was going to scale and grow to the needs of the largest customers.
What were some of the observations that you made from coming in and seeing where they were at and wha the opportunities were? What were some of the things that you really wanted to make sure you kept an eye on?
Shiven: So at Auth0, there were two motions there. The freemium self-service is product-led but Auth0 established a sales motion very early on. And I think that’s really healthy. Sometimes companies do that much later, but I think they had a really good balance of making sure that, “Well, we are going to start landing larger customers, they have different needs.” And so the balance at Auth0 was making sure we’re not messing up the freemium self-service tier. Even simple things like making sure the pricing is scaled to them.
For example, when I arrived, I know the first two tiers had this nice scaling, and then literally there was an enterprise tier. It was like, whoa, this is jarring for the customers. And we’ve tuned that over the last year and a half. But speaking of the enterprise components, when you start selling to enterprises, and I know some of this has been covered in previous panels too, you now have to deal with analysts and helping educate them.
With enterprises you have to do those things. We spend a lot of time with Gartner and Forrester amongst others. We also build enterprise-readiness features.
Everything from compliance to even simple things that we take for granted. Enterprise is a very complex team-based axis and roles. So you have to build that, and everything has to be auditable. You have to build auditing into everything.
Those are the types of things that we had to balance out with the product teams where it wasn’t about just launching the latest password-less capability or feature or MFA, it was also about making sure, well, we really have to mature our capability in how we talk to our customers. Even things like having support plans and premier support plans, because when you start moving up market, there are additional requirements that you need to solidify.
Adam: Absolutely. The one that always comes up is how do you actually, within your platform, show value? And ultimately it comes down to some type of reporting or charting of usage. You think about it as a requirement for a large organization.
They have so many tools, they have so many products that they use and how are you making it so that your organization, your sales organization, your support organization can actually show that value very quickly and easily, based on usage statistics or based on some type of data that is going to be that thing that your internal champion takes and says, “Look, this is really valuable to us.”
It’s so imperative that you’re not just saying, “Well, I want to have good ergonomics for an individual developer, so that there’s low friction for their usage.” Yes but that developer probably is not going to be in the room when you’re having those larger sales conversations. You can ignore either one, but it means that you need to be mindful of both.
Shiven: I think reporting is a really good example. The other example I would use is, as you mentioned, larger companies just have so many different tools they’re already working with. And so one of the things, one of the insights we had was, in addition to billing and reporting, just integrating into existing tools like Splunk, Datadog, and Sumo Logic. There are some other ways where you can quickly add value, essentially meeting developers where they’re already using the tool at the end of the day.
Adam: That’s such a huge point of this transition from that initial product-market fit and an early stage of when you’re building a community, to building a platform and being able to engage with not only community, but the ecosystem. All of a sudden you’re thinking about it in the context of, very seldom is anybody able to build a end-to-end encapsulated, I-do-everything type product. Hardly ever happens.
More often than not, your success is going to be dictated by how easy it is for people to insert you into an existing environment. And how easy it is for them to have really well-defined inputs and really accessible outputs? Your product is going to be in the middle somewhere, so how do you make it so you’re being a good neighbor with all of those folks? This is something that I saw Auth0 do extraordinarily well, it’s the integrations that matter. And seeing them before it becomes a blocker for a customer.
In your experience, as you scaled and as you grew those integrations at Auth0, were there any gotchas that came up? I know that Auth0 has a very strong culture of API-first and I’m thinking about that, but what advice would you give or what lessons did you learn as you were scaling that out?
Shiven: A couple of things on integrations. We started integrations on an ad hoc basis. And so the first problem was they were all over the place. When you’re doing integrations, you have to think about discoverability and finding the integrations at the right place and the right time. So we had integrations fall all over the place. Finally we said, “This doesn’t make sense. We need to have a good place to discover them.” So we printed a catalog. That was important.
The other part, especially if you are API-first, is trying to make the integrations self-service. Our first 40 to 50 integrations, we had to handle them and we were maintaining them and making sure that they were current, but it doesn’t scale beyond that. We’ve been investing a lot in self-service tooling, so that 1) other integration partners can just get going on their own because they don’t need us for everything. And 2) so that you can actually scale. You can add lots of integrations in a fairly quickly way, and you can automate.
Make sure integrations are secure. Make sure they’re supported. If we had an integration that was being deprecated or end of lifed, we made sure to gracefully propagate that to our customers. Automating them actually helps because you could spend that time onboarding new integrations. Thinking about self-service is critical.
Make sure these integrations are essentially software products. So having a product detail page with relevant information about how you handle support. Is there a cost to using the integration? Are there any prerequisites for it? Some of this stuff is very relevant to the ecosystems. These are some of the things that we had to bring in and change. And it’s still a journey, we’re not done.
Adam: One of the points that I make often when I’m working with folks and this was definitely something that I pushed strongly recently at LaunchDarkly while I was there, as well as while I was at GitHub, was you need to think of your integrations as part of your product. For folks who haven’t read Mik Kersten’s book, Project to Product, highly recommend.
And you need to think about it in the same way that you would think about integrations as not just a project with a “ship and done” end state that you’re executing on.
You need to think about it the same way you think about your products. Look at what the opportunities are for innovation or updating.
Maybe that’s further integration, maybe that’s making sure that you’re incorporating that into your test suite so that you’re doing forwards compatibility with those individual integrations. Ideally, you’re making sure that you’re proactively engaging with those organizations so that you know what they’re working on.
That’s where you would get some amazing happy accidents, where all of a sudden, you’re both having this vision of, “Oh, I really want our customers to be able to do X, Y, Z,” and the same perspective is shared by this partner or this integrator, and you can actually get there faster, or potentially get there in a way where you really get the effect of one plus one equals three. That’s where the magic happens. If you can create an abstraction layer for development of integrations, you can even accelerate that further.
As you start to look at this third stage of growth of really massive scaling and getting into category creation and this massive adoption as you go further down the adoption curve, we’d be interested in your thoughts on how this early work, what you’re experiencing and what you’ve seen, how that supports this later stage growth.
What are some things that you’ve looked at as you’ve been through this a couple of times, that you’d be like, “Yeah, I made sure that the next time I’m going through this, I’m putting this in place a little bit sooner, or I’m holding off on this part a little bit later.”
Shiven: One asset that continues to pay off really well for developer products is community. If you invested early-on in building a community, that’s the one thing that you don’t want to lose. And if you engage with them, if you have good feedback loops and you maintain your authenticity, even when you make mistakes as you grow, if you have a good relationship with your community, you will get a pass along the way.
We made mistakes as we were scaling things up. At DigitalOcean we had outages, we had reliability issues, and developers were very forgiving and understanding because we were very authentic, we were open about what we were trying to do to improve the situation.
The same has been true at Auth0, where again, as you’re scaling you run into scaling challenges. In the Auth0 case, the community has been helpful in that they’re really eager to try new things. Because of that credibility we’ve built, when we’re launching new capabilities or testing new features, they’re a good place to try out things. When we’re releasing products, for example, we actually sometimes turn a lot of new features on in or freemium or free tiers so that developers can play around with them, and create a healthy loop.
The other part is, when you are scaling, and I think especially if you’re going to sell to enterprises, you have to start investing in reliability early-on. I like what Jeff from Twilio had said about “we’re in the business of growing business.” When I say, “What do we sell at Auth0?” the internal answers I get are usually. “we’re selling identity as a service or authentication as a service.” I always like to say, “Well, no, you’re actually selling trust, because that’s the thing they’re buying from you.”
There are lots of nuances to trust, but reliability is an important one. That’s one thing I’ve seen every company, especially during the growth stage, fall behind on, and that’s an area I would recommend you start much, much earlier in. Building resiliency and disaster recovery.
Adam: The two that I would add to the list that I’ve found to be extraordinarily advantageous to start doing earlier rather than later, one is compliance.
Adam: It is so much easier to get SOC compliance when you are 15-16 people than it is when you are 160 people. When you start to think about compliance standards and quality assurance standards as the instruction manual on how to operate more consistently, instead of an undue burden that you’re putting on your operations or infrastructure team, it changes your mindset a little bit.
All of a sudden you realize that this is giving you the actual ability to move faster and more confidently, as opposed to something that is just getting in your way.
The other one that I’d say is be aware of confirmation bias. And this is something that oftentimes comes up in the go-to-market side of things, either in your marketing or in your sales motion of if you’re starting to think about how you’re going to scale and grow your sales organization, think about outbounding early.
The reason for that is because if you’re only reliant on inbound, not only is there the strong potential that that well is going to dry up or not be able to scale the way that you need it to, but you’re also going to be staying within a bubble that is very comfortable. And all of a sudden, you’re going to start having conversations with larger organizations, whether it’s because they hear about you or because you start doing that outbound, and they’re going to be asking for things that have never come up before.
So the earlier you start understanding, even if you get shot down and, “No, you don’t have what we need,” at least then you know what they need and you can make an informed decision of prioritization of, “Are we going to build that now or not?”
Those are the two that, having been through this a couple of times, I’d say have those conversations with people that you just don’t expect to win the deal with, but understand what their needs are. And do things well and follow the best practices that you’d need at scale, oftentimes it’ll help you early on to actually move faster. Thoughts on that?
Shiven: I agree with compliance. It’s much harder when you’re a bigger org. It’s really, really painful, so starting early is good. Your point on talking to buyers who may not be your buyers today is really insightful. I’ll share some examples. We didn’t do that at DigitalOcean because we were so reliant on the community. So we missed a lot of the capabilities they needed. The Teams feature and RBAC capabilities at DigitalOcean came much, much later.
The reason was, we only started hearing about that when we had larger customers. They would tell us, “there’s no way I can manage this infrastructure the way it’s set up. Great, you have a droplet page, but we have 2000 droplets.”We didn’t realize a large company would have to build them up.”
At Auth0, we had a similar experience with deprecation strategies. When you’re dealing with the developer community, you can send them an email and say, “Hey, in 4-5 weeks, we’re going to deprecate something.” And you get away with that but it does not work with enterprises. You have to give six months for lead times-
Adam: Or when I GA this, I’m making a minimum commitment that I’m going to support it for three years.
Adam: I don’t even know if that code is going to exist three years from now.
Shiven: These are the types of things you may not be aware of, but it’s good to know. Especially if you’re going to be a critical part of the customer stack, these things become really, really important. And again, Ijust a simple thing like deprecations in a developer community, much more easier to deal with, but when you’re in the enterprise land, expect that to take a long time. And like you mentioned, I think they’re in some cases expected to last years too.
Adam: It’s interesting, because I think that there’s another part of that communication transparency that I think we’d love to get your take on, that I’ve seen be so important. And that’s the transparency with regards to feature functionality. And when you have a robust and a vibrant community, you really need to be thoughtful about who you’re going to build a feature for. And it’s not necessarily always as straightforward as, “Well, who’s going to pay me for it?” You really need to think about it, especially for organizations that have strong developer communities, who’s going to get value from this?
And then what is that measurement of value that is potentially monetizable. The one that always gets me is when I see developer tool companies charge for MFA (multi-factor authentication). That does not make sense to me. This is something that is a best practice for our industry that we should be encouraging everyone to do, even individual users. And that is not something that we should be putting behind some type of paywall.
I’m interested in your take on this idea of, how do you either do that assessment or walk that line with the developer community that you’ve built, to ensure that you’re continuing to build that trust as opposed to tearing it down?
Shiven: The key is to keep your feedback channels open with the developer community. There are different approaches. At DigitalOcean, it was almost like we were developing in the open. Every feature request was logged. I would go in or the co-founders would go in and say, “Hey, yeah, this is coming in Q3 of next year,” or whatever. And it was a very active feedback loop and it worked. So we built it and we communicated fairly frequently about the roadmap and what’s next.
At Auth0 I think it’s been slightly different because we were getting feedback from all of these channels, but we also we had this ambassadors program where we get feedback from support channels, or customer success, SEs, support tickets, and obviously sales people just from the sales organization too. So we’ve been taking feedback from different constituents, and then feeding back into the roadmap and communicating that.
And again, especially when dealing with enterprise, the key is the frequency of how we communicate and the details. The other thing that’s important to remember is not all enterprise users are going to read your blog.
So if you assume that you posted on the blog and it’s going to work, forget about it. There is so much noise.
Different companies have tried to use some of these different approaches, like customer advisory boards. We do a lots of webinars, and that has been a good source for how customers get insight into the roadmap. There are also user groups and round tables, for example.
So again, focus on enabling the developer, but also engage with different communities too, because while developers are influencing the decisions, they’re not the ones who are writing or managing the budget and writing the checks. And so we make sure that we’re able to reach the folks who are writing the checks, in some other manner, because they’re not going to be on your blog.
Adam: Absolutely. I think the other thing to recognize is and something we talked a lot about at GitHub is that developers have a lot in common as individuals in terms of people who love building stuff. But I think something that’s extraordinarily important to recognize is that the needs and the priorities of a developer that’s working independently or at a small startup or small team are probably going to be a little bit different from those that are working in a large established enterprise company.
So how do you make sure that you’re hearing all those voices? I love your points about building an advisory panel or an ambassadors program to be able to hear from those individuals. We’ve also seen in various roles that I’ve had, doing outbound surveying, or just even having a good user experience team or developer experience team that is doing proactive interviewing with folks on a regular cadence.
Shiven: That’s a really good point. We’ve invested in a research function and we’re constantly doing research, and also building a research repository internally that our product teams can go and consume. And so I agree. If you’re not going to get all of the feedback through meetings or support tickets,you have to proactively go out there and source that. So that’s a really good investment. I would highly recommend it.
Adam: Absolutely. Well, I really appreciate your time and all of your insights. Hopefully the audience has as well. I’m excited to see how Auth0 continues to reach new users and take advantage of working with Okta, to be able to build some great solutions. So thank you very much for your time. I really appreciate it.
Shiven: Thanks, Adam. Appreciate it.