Developer Marketing at Auth0

With guest Gonto and hosts Matthew Revell and Adam DuVander

Gonto, a pioneer in developer marketing and Auth0’s first developer marketer, reveals how he set out to build a version of marketing tailored for developers. His innovative approach played a key role in driving Auth0’s growth, ultimately leading to its IPO and $6.5 billion dollar acquisition.

Episode outline

01:10 – Gonto’s start at Auth0: Gonto explains how he joined Auth0, shifting from a developer to a DevRel role, and eventually taking on marketing responsibilities despite his fears.

02:31 – The shift from developer to marketer: Gonto talks about his friends' skepticism and how he wanted to prove marketing could be done differently, with honesty and authenticity.

06:00 – Should your first marketing hire be a developer?: Gonto discusses whether the first marketing hire at a developer tools company should have a technical background.

08:43 – A different approach to marketing: Gonto describes how his background as a developer helped him shape marketing strategies that are genuine, data-driven, and based on systematic thinking.

11:30 – Developer trust and marketing tactics: The conversation shifts to how Gonto built trust with developers by offering honest, helpful marketing content, and solving their problems without aggressively promoting Auth0.

13:02 – Choosing the right developer audiences: Gonto shares insights on why they chose frontend developers and specific technologies as key targets in the early days of Auth0.

15:22 – Repeatable marketing processes: Gonto offers advice on how startups can find the right developer audiences and communities by staying informed about new technologies and frameworks.

21:30 – Marketing to multiple audiences: The discussion moves to marketing when different technical audiences are involved, such as DevOps and developers, and how to convince multiple stakeholders within an organization.

24:20 – Enterprise sales and developer involvement: Gonto explains how the majority of Auth0’s enterprise deals came through inbound developer interest and the steps they took to convert developers into enterprise customers.

29:00 – What didn’t work: ads: Gonto shares some of the tactics that failed, including poorly targeted ads and struggles with hiring product marketers who didn’t understand the technical product.

34:00 – The importance of metrics and systematic thinking: Gonto reflects on how metrics and systematic thinking guided his marketing strategies and helped the team track success, and how over time he learned that creativity can matter more than data.

Transcript


Adam DuVander: Welcome to Developer Marketing Stories. I'm Adam DuVander.

Matthew Revell: And I'm Matthew Revell. Now in this episode we're going to be talking to Gonto, otherwise known as, Martin Gontovnikas. And if you haven't heard of Gonto himself, then you've certainly come across the tools that he's been instrumental in bringing to market. So in this episode, we are going to focus largely on the story of Auth0, where he was the first marketer, but he's also worked with companies like Retool and Vercel these days. He's one of the founding partners at Hypergrowth Partners, and if you're a startup founder, you might want to go and take a look at what they do. And

Adam DuVander: Before we get to Gonto's story, we want to invite you to be part of the coaching and training programme at Developer.Marketing. It's a project Matthew and I are working on to help you elevate your career in a developer marketing or DevRel role. So go and check that out and join us there at Developer.Marketing

Matthew Revell: Gonto. Can you take us back to the moment where you had become responsible for growth marketing at Auth0? What was that moment?

Gonto: That moment in particular was very weird for me. I had joined Auth0 to do DevRel, which I've never done before that I didn't know what DevRel was, but I knew that I didn't want to programme anymore and had broken up with my girlfriend and then was realised that I didn't want to do coding and actually wanted to engage more with people. I read a book on developer evangelism and I liked it, so I ended up joining. After joining there, we started to write content to do tools and a lot of things started to work out. So then John, who back then was the CEO, he came to me with this idea of giving me the chance to lead what back then was called self-service. And at Auth0 back then all of the revenue was self-service. It would be what you now call growth. But back then it was literally self-service. And I remember that at that time I was in a self there for three months actually speaking at meetups, and it was so fucking scared because it's like I've never done DevRel before. Now I need to do something that is self-service, which includes marketing, which I know even less about what the fuck am I going to do. So I was extremely worried, super scared, but of course I said yes just because I like the adrenaline and the opportunity to do something different and unique.

Adam DuVander: Were there people that you talked to at that time? Did anyone say, you're a coder, you're crazy to go to the dark side?

Gonto: I talked to a few friends, a couple of them were like, are you going to like marketing? Marketing are people who are full of shit where they make up stories, where they convince you of things that don't matter? And actually in part, all of these anti recommendations from my friends helped me think, what if I can do marketing different? Why do we need to do that same old style marketing that people don't like? So that got me excited. And the other thing that got me excited is that every time that I did a good shop change in my career path, my parents told me not to do it because they were scared and they wouldn't change and stuff like that. So the fact that my parents told me that's too much, it was like, okay, this is the thing that I got to do.

Matthew Revell: So what was the initial pitch of Auth0? I think it'd be interesting to hear that because there were authentication and authorization tools around at the time. So why did Auth0 exist?

Gonto: So when I joined, it was very early. I was a six employee. I didn't really fully understand what Auth0 could become to be, if I'm honest. I didn't think it was going to become this huge, but I liked the idea of there's so many things around authentication that I don't really understand. And I honestly joined mostly because Guillermo Rauch who is now the CEO of Vercel told me he invested in Auth0 and that I should join and I blindly believed in Guillermo.

Having said that, I remember that first week that I started, I spoke at a conference and I flew there with Mattias, the CTO and founder, and we spent the entire night up where he explained me authentication of OpenID Connect, and all of the things that I've never heard. And what to me was fascinating about Auth0 was that back then all of the authentication services that exists existed as a way of a widget or a plugin that didn't require coding.

So it was like a widget for WordPress or something that you could add to your employees or something like that. But there was nothing that was actually targeted to developers because everybody thought authentication is so boring, nobody wants to do it, nobody cares about it. There's no developer that would ever think of using it. So our whole pitch, what was unique about it is we are entirely targeted to developers. If you're a developer, you want to add authentication, you don't want to mess up with potential security mistakes or bug or errors and get hacked. You can decrease the probability of getting hacked by adding Auth0. Adding Auth0 requires you three to five lines of code and once it's added, you can with a click on a button on it, you can add Facebook or Twitter or Windows users or database users or multifactor or whatever.

But all of those extra changes didn't require extra code and therefore it was very easy for developers to use it and get it done.

Adam DuVander: So you mentioned that you have that conversation that you had where he describes everything about the stack. You're a dev, you can take that in.

How much of that do you think was the success that you have this dev background or you're advising companies a lot now? Now for that first marketing hire for a dev tool, should it be a dev, should it be someone who has the marketing skills? How do you look back at that moment where you were put in that spot?

Gonto: I think the fact that I was a dev made it a lot easier. I don't necessarily think that you need your marketing leader to be a dev. I do think that you need somebody who after talking to you for a couple of hours or an interview, they can understand and explain the product. So they have to be technical enough where they get it. I've seen so many product marketing people who don't get it and will never understand, and if they don't in a couple of hours, they never will. So I think it is an unfair advantage in some form of sense.

When I think about startups now on who is the first hires they should do, I think if they send to developers and they do product like growth, I always advise them with two main hires. One is developer relations and the other one is what I call a growth marketer or growth strategist or something like that. Why? First of all, because I believe you need ics. I don't think you need people who are managers because otherwise you spend three months hiring the person who can get any shit done and I need to hire somebody else for three months or six months. So I think hiring ICs (individual contriburos) is important.

I think DevRel will give you somebody who actually understands the product, who can be creative, who can build and do technical things. The main thing that I think important with DevRel is that when you're a startup, I'm personally a big believer in hiding what I call people with hunger for glory. Meaning I prefer to hire a DevRel that has never been DevRel before because they have something to prove and they try harder and they work a lot more on making sure it works. So you could potentially find somebody who has written good blog posts, who has spoken at some meetups, who engages with the community on Twitter and Discord, but has never done it before.

However, this DevRel personality, I think they're pretty bad at looking at numbers and at thinking of things as projects. I think in general, they're not very organised on thinking on the projects and what is the hypothesis, what are you going to try, what is the metrics and why? And that's what the growth person I think adds the growth person adds this framework around doing things. So if that work has an idea of something to try, growth can like, okay, we want to try this for what is the main metric that we want to change? How are we going to test for that? How much time are we going to run it? How much time are we going to do it?

So I think the two of them are a dynamic duo that I think work really well together and they end up complimenting each other a lot. But I do think you need somebody technical like DevRel to be one of your first two hires or whatever dev tool startup you do.

Matthew Revell: So let's go back to you've started at Auth0. You've been offered the opportunity to do marketing, and you said earlier that you had decided to take a different approach to marketing. Let's talk about that. What was that approach?

Gonto: So the approach was more around a couple of things. One is I believed that it was important for us to be genuine as a developer.

The first thing I thought when I was given marketing was what are the instances that I live marketing with? And one of the first ones I remember is actually going to Zara or to Levi's to buy a gene or something like that. And the main thing that I despise is when people come to me to help me out and then they're like, oh, everything looks fantastic. It's incredibly new and I feel that that's marketing. I always thought that that was marketing. So to me, doing marketing differently, implied being specific, being honest and being genuine and just being helpful to people in general.

So I was on the one side on the other side, I didn't know what marketing was. So the only thing that I knew how to do was apply systematic thinking from my engineering college. So the idea was what if we apply the scientific method over KPIs, which back then it was signups and self-service to try to drive them and make them move forward.

So that's where a lot of the things came. The first thing that we did for example, was even though I was a developer, I tried to interview frontend developers who never heard of Auth0, which back then was all of them to be honest. And when we interviewed them, the questions were how do they relate to indication? What do you want to learn about in authentication? What do you want to learn about? What communities are you part of? Who do you follow on Twitter? Are you in ready? Do you go to conferences? What do you do? And the idea of that was that most people in marketing want you to come to ask to see things.

I believe that if you want people to notice you, you come to understand developer's, habits adjust, tap and exist and show up in those habits. So when we decided to do something different was this first step where, for example, on the interviews we heard from all of the developers that they didn't give a shit about authentication because it was the most boring thing in the world for them and that they would only carry out indication if they were told to implement it and they would look for something open source or they would try to implement it, get an error and get stuck.

Back then our competitor was Okta for example, and they were writing content for single sign-on refresh tokens, and which are very technical terms for authentication. And based on what we heard for developers, that made no sense. So for example, one of our first tactics that worked was starting to build landing pages where we tried to implement Auth0 with Angular, with jQuery. Remember it was a lot of years ago on different type of technologies. And then for every error that we got, we created an authentication error, how to fix it, and they say something like, if you want to try it yourself or you wanted something more advanced, check out Auth0. And that's where it started to work because it was part of the path. We literally were helpful to them to solve it, and we only told them to use Auth0 if something else like that happened.

One other example I can give you similar to this was in conferences. Every time my developer came to a conference to us and asked us, Hey, I want to add Twitter auth, should I use Auth0? Our answer was always no. If you only want Twitter app, you don't want use and password, you don't want anything else, just call the APIs. It makes no sense. It's one sdk.

However, if you want to start adding multifactor authentication, use password, import things and different password, et cetera, then you should think about it. And that's the other thing that I think started to create trust because we were honestly being helpful and delivering them the honest message on when we thought the product was useful to them.

Adam DuVander: It sounds like you learned a lot by talking to devs and then of course you being a dev. But one thing at the top that I noticed, you said you went to front ends devs, so I think a lot of marketers listening to this might not know immediately which devs to go to. How did you choose front end devs?

Gonto: That's where being a developer I think is helpful.

When Auth0 was starting was the age of single page apps and they were blowing up. The other thing that was blowing up was the jam stack, this idea of you're building a JavaScript app, you have an API, and then you just call the API. And there were so many people trying to figure out how to think out authentication a single page app because before authentication was always in the backend. You would click on something, it would refresh the website, get a call back to something else, and in this case we saw so many people that were trying to figure out how do I do authentication for front-end applications for a single page app?

And people didn't know Auth0 would work both for backend as well as for frontends. But because we saw in the market that people didn't know how to do it for single pay shop, we thought that a frontend developer was a better hit for us back then. So that's first how we decided frontend developers.

The second thing that we decided back then that also we couldn't have done it if I wasn't technical, was this idea of betting on technologies. The one thing that we thought about is I knew from being a developer that some communities, even though they don't say hated each other or didn't like each other, and it's like, no, I remember ember js with Angular back then and it's like, no, my style is better and stuff like that. So we tried to think everything about what are the communities that we need to get in and we separated them into what we called up and coming and established.

So the idea was an established community has thousands and thousands of users, but it's very hard to get in and up and coming. One has very few people, it's easier to become a thought leader or be part of the community, but then if it grows, it blows up. If it doesn't, it was the wrong bet. So back then we decided on front end, but we also decided that our established community was going to be backbone, which back then there was a lot of people that were using, it was an MVC framework and our up and coming was angular js, which back then it was 0.6 and we thought it was going to blow up based on how it was helping.

So half of the frontend team that we interviewed were actually Angular as well, and that's why possibly there were so many errors as well in that community.

Matthew Revell: Is there a way to abstract that into a repeatable process? So right then there were some steps you took that were, they sound repeatable, but there was a lot of very time and space specific stuff going on there. So if someone were to come to you and ask for your advice on how do I do this now, what would you say?

Gonto: I think you can still do it now, but it's more about timing matters in everything in life. So continually be watching on what's happening with the frameworks, with the technologies is key.

For example, on dev tools, what I think a lot about now for example, is I've seen that all of the next JS now has React server components and it's this new server, it's starting to become and look similar to PHP. Laravel raised 62 million in funding and now I seet on some of the YouTubers starting to talk about Laravel. So Laravel could be one of the things you be on just because JavaScript and front and is starting to become more like PHP, even though it's not the same Laravel is trying to get there. Is it event, I don't know, maybe it fails miserably, but it's one thing that I would think about. But to me it's more about being on Twitter, looking what people are talking about being in discord and in Slack communities and seeing what are the things that are happening to decide on what to focus on. The two bets, for example, that worked for Auth0.

One was AngularJS, the other one was next. So we didn't bet on React, but on next what we did saw we did see is that it's an easier way to create applications. And when it was very small, we started to create SDKs and frameworks and everything and then we were able to tap the community. But in a lot of cases you have to be constantly watching and sometimes you'll bet wrongly. I remember we betted on VueJS that it was going to blow up and it didn't. So VueJS was a wrong bet, but at least we gave it a try.

Adam DuVander: And so it sounds like at the beginning you had one established and one up and coming, and those were your bets, the established pretty solid bet.

The other one, maybe a little less, but you were able to put attention on two. As time went on, you were able to add other, it sounds like especially new ones, but maybe established ones also. And in this case it was frontend frameworks for someone else. I mean the other examples you gave, there were more backend tools and so depending on what your product is, finding a complimentary tool, finding a set of complimentary tools, which did your interviews from devs help you decide on those initial bets too?

Gonto: No, not really. The initial bets, to be honest, came less from the interviews and more from researching on Twitter and going in person to conferences and chat with people in the conferences on what they were up to, what they were thinking about. So it was more about being embedded in the community.

We did the interviews specifically from people from each of the technologies that we picked just to compare and contrast the differences between one and the other. But we always followed people on Twitter, followed special discords and slack with engineers, listen to podcasts and stuff like that. So that's where I think it's repeatable, but it requires somebody who understands the industry and can talk engineering so that they can understand some of the things. But I do think it's something that is repeatable.

As time went by without Auth0, we picked more up and coming and more established. So we did both things even in backend and stuff like that as we started to grow the team as well. In a lot of cases, these communities aren't a framework. For example, for one of the things that we picked was a community of people that were frontends, were performance obsessed. We found actually a discord or a slack were people saying, oh, my paint took 36 milliseconds, yours took 28. And for Vercel, that's great because with serverless it matters the performance, like how much better it is. So it doesn't have to be a framework, but you have to find some group or something that aligns well, I think with what you're really,

Matthew Revell: So lots of marketers who have come from non-developer marketing will probably want to turn to a defining personas, doing market segmentation, that kind of thing. Do you think people need to do more than only look for these technology communities?

Gonto: I think that to start, you can just pick something like that and go after them. But I do think that for example, a DevOps, a developer operations is very different to a developer now.

Also there's SRE, like site reliability engineers. How is an SRE similar or different to a DevOps? How do they think about services? So I think in parts it's important to differentiate them just because there's small differences into how one thinks and how other thinks in the funnel. I think a lot about the developer funnel is very different to a typical funnel. I think of developers on trying to learn and explore new options then doing a demo and then if the demo works, they sell internally and eventually you get it, which is very different to others.

And I think maybe with a DevOps or an SRE persona, it changes even more because sometimes the DevOps or the SRE needs to implement it, but the developer gets the value. If that's the case, why would they do it and how to think about it. So that's the only extra thing that I think is important. I don't think you need to do this. Bob thinks this and they feel like this and these persona cards that I think are very fake, but you do need to talk to them to understand how they make decisions, how they look for things and how they relate to those.

Adam DuVander: Can you take us through, it sounded like in your example there, the SRE is the buyer and the developer gets the value. Is that what you said? Or if that's not the case, give an example where there's sort of those two different audiences that are both maybe technical and then what they're looking for and how you can give it to 'em.

Gonto: So for example, one of the platforms that we worked with was a platform orchestrator, one of the companies, and in that case it was an SRE or DevOps that was setting it up, but then the value on making it easy to deploy new things to station to try them out, et cetera, it was an engineer. So in that case, I think it's a lot harder to do product-led growth because the person who needs to set it up isn't getting the value. So what's the value that they get? What's their incentive to implement just the developer happiness?

And I think in those cases, it's harder to navigate and to think. And in those cases, what I typically try to do is find ways for either the developer that gets the value to push on DevOps to implement it, but you do a lot of the marketing to the developer instead of the DevOps. In other cases it's you need to explain the DevOps, how if the developer is happier on this, then they can actually spend more time on doing shit that matters instead of that.

But it's a different message that you need to convey and how you sell it to others. One thing I've done with a lot of companies to help with this is what I call how to convince your boss. I think developers are, they are not that good at convincing other people or selling.

So a lot of cases what I do in these cases is I get this developer who will get the value and I give them a pre-written Slack message on how to talk about this with a DevOps. I give them one or two links to blog post on things that will be interesting to the other person and stuff like that that maybe is fine tuned for their use case, what they are doing and why.

With one of the companies that I work, we actually created a fine tuned model of OpenAI based on all of the different use cases that the company has based on different personas and some of the small training there so that it actually creates a slack message that is tailored to specific companies and specific examples. And that helped us a lot on internally selling this to other peers and people in each of the companies.

Matthew Revell: And I think that's interesting because in a lot of companies we think about developers with their credit card and self-service, but actually there's so much more now of companies where developers are an influencer or they're an implementer, but they're not the final decision maker. Would you say that you then, over time at Auth0, did you find more people like that? Was there a move to an enterprise sales model? And if so, did you go out and find mentors in marketing who could teach you the B2B side of things after being a non-marketing yourself?

Gonto: So what's interesting about Auth0 is that even though 92% of the revenue were enterprise accounts and 8% was self-service, of that 92% that was enterprise, actually 82% came inbound. So it still came either through a developer or something similar instead of outbound.

I did hire somebody, her name is Carrie Oak, she's fantastic, and she was the one who created the more typical B2B motions by going to events, doing a VM and stuff like that. She's actually now the CMO of Okta and she showing on my team, she was my VP of demand gen to help build all of this.

Having said that, I think there's a lot of ways where once you have a developer trying out the platform that you can sell to directors of engineering or decision makers in the enterprise. To give you an example, one thing that we've done with Retool, for example, with one company, it's an internet tool.

Apps that I worked in the past was if we see a developer that is trying the platform and we see that the developer is from Coca-Cola, we start paying attention into activation and what steps they're taking into their product. Once we see they've actually used enough where they are getting value, one thing that we do is we send them the how to convince your boss package.

And at the same time we start doing ads on LinkedIn to engineering managers and directors of engineering in the company. We don't do the ads with the ads, just go to the home. So the ads don't have the intention of conversion.

The idea of the ad is that if the developer goes to sell to the Engineering Manager or director of engineering because of availability bias, if they've seen the ad, it's more likely going to be, oh, the brand sounds familiar, and just more likely to open to hearing out.

After one week of doing only ads, we start sending some emails like, Hey, we know you have three developers or two developers in the platform, they've implemented this so far, have you connected with them about what they've done? So we do emails that actually target engineer that are focused on what has been implemented, what's been done, just based on at least the data that we know. So we try to create these connections between one and the other and to make them talk. So by doing that, we've found a lot of ways of accelerating this connection, this conversation. Other ways we've done this, for example, is we see a lot of this pattern where developers first sign up with a email address and then eventually they sign up with a corporate email address when they're more likely to be discovered because they do those things typically on the same computer. By using the identify cookie from postcode or segment or whatever, you can actually link the emails.

So by doing that, we could actually guess using a predictive model, which Gmail accounts were actually corporate but didn't want to tell us before. And we guessed approximately 78% of them, which was a pretty good number. So based off of that, we would give them special supports, special things to those hidden people without talking to them by trying to having them have a better, faster experience to eventually convert them to enterprise.

So these two examples, what I try to say is selling to enterprise doesn't mean it's not PLG. The biggest deal at Auth0 was Atlasian back then they paid 2 million a year on revenue and they came because the CTO tried our docs and did a contact sales through the docs and his pet projects thing. So they can come, you just need to be able to notice them and handhold them and help them out maybe a bit more.

Adam DuVander: And if I'm hearing some of the things you didn't do once you notice that someone from Coca-Cola is there, you didn't say get on a call with our salesperson, it sounds like there are things that you're doing to how do you identify the things that will help them as opposed to obviously that get on a call with our salesperson would help us, the dev tool, right? How do you differentiate those things?

Gonto: That's where I think being technical or being a developer helps out where it's like, if I would fucking hate this email, we do not send it. So in that sense, I think it's a bit easier, but I would say we do not knock them with things that are not relevant or useful for them.

For example, with Vercel, we did something different where they used to have SDRs or BDRs, these junior salespeople, and they weren't helpful. So we ended up switching two things. First of all is we created something where we could predict if people were getting blocked in the dashboard. So for example, if somebody click on a section in the dashboard, go to Docs, came back and did nothing, likely they're blocked. If they click on a section, go to another, come back, they're lost.

So we found patterns that we knew if people were blocked after doing something. In those cases, we were like, okay, this is a great time to reach out. But we didn't want the SDRs because they weren't technical. So we actually hired people from Apple Genius Bar from Best Buy Tech support and from CS boot camps, which were a bit technical, we gave them a course on how to be more technical and understand the platform. They were still cheap because an SDR has to be cheap. So we actually trained them on how to help people when they were blocked. And then when somebody was blocked, we helped them out. And once they were unblocked, they were like, Hey, no pressure, but if you're interested, I can connect you to sales. I'm not sales, it's somebody else. If you don't want to, that's fine.

So it's more like a soft thing. But because we help them out, they felt they owed us. And what they typically said is, I'm not going to do this sales call, but let me get my engineering manager to go and meet, which is exactly what we wanted. So by making it based on adding value on what they were blocked and softly pushing, it worked much better. It sounds like Derel Light is that we called them product advocates.

Adam DuVander: There you go.

Gonto: That was the role.

Adam DuVander: For them at least. So during this time when you're trying things, you've told us a lot about the things that worked. What were some things that totally didn't work?

Gonto: Ads. Ads was by far, I think one of the first one in the beginning where I do a mea culpa, I didn't know anything about ads. So we spent, I remember one month, 200 k in ads and we brought people from back then from India and Pakistan, which were not our target market, and we spent money for nothing. I remember feeling so fucking bad about it, but in general, I think ads was something that worked. Once we started to focus on directors of engineering, engineering managers, we tried with developers and we were never successful.

Having said that, I've seen companies now like Tiny Bird, which is one of our customers that actually is successful doing ads for developers because they are relevant, they're funny, but that's something we didn't do well back then in Auth0 that I think was one of the things that was always hard. The other thing that I think we failed at miserably is product marketing. We changed and hired and changed the product marketing team so many times there.

And I think that in product marketing, one of the problems we have is I people not technical enough. And actually I've seen more product marketing people that are bad than good, and it's mostly because they try to talk in what I call value propositions, how this thing is going to help you. And they use what I call magic words, like this is going to be seamless. What the fuck is seamless? What does it mean? Or they put three adjectives per nouns or stuff like that. And in the end, all of the copy that they wrote was always so bad.

So we ended up doing something in other companies where what we do is we actually pair a DevRel when their standard technicality, but maybe it's not as good at writing copy with a copywriter. And that ended up being much better than the work being done by product marketing. I've seen good product marketers. Vercel has very few, they have only three, but they're one of the best technical product marketers I've seen in my life.

I just think it's so hard to find and hire good ones that maybe you do this hack of derail with a copywriter instead of the other one. But that's something that I always felt that we never did a good job at Auth0 in neither of the seven years that I was there. Having said that, we got good feedback for the copy on the website and the content because what ended up happening is that there was a copy that they created. I went in or somebody else went in and they changed it. But that's fixing a problem more than actually making it right from the get go.

Adam DuVander: And when you say that most of it was bad, it was because to a developer's eye, it sort of hit some of those words that you don't want to see.

Gonto: I personally think it's bad for all. It's this copy where they talk about the experience is seamless and you're going to reduce your cost and increase your revenue from what I personally believe that even if they're not dev tools, you should be specific about what you do and you should talk about your differentiation. Differentiation with developers even more. But I think it applies to all, and I think product marketing in general doesn't do that.

Matthew Revell: The word powerful is so meaningless, it always makes me cringe. I'm really interested, and I know Adam is in everyone's story about metrics and measurement, and I know that you mentioned systematic thinking at the beginning. So take us through how you built the metrics that enabled you to succeed.

Gonto: So first it was all back then, remember, growth wasn't the thing. So a lot of the metrics that now didn't exist back then. So at first we started with signups mostly because it was like, okay, we want to get more developers to try a platform. If we have more developers trying it'll work. We actually realised that signup wasn't the good metric when we did the ads experiments because the ads, we got a lot of people from Pakistan, which we didn't care about as a company. So then it was like, okay, we need to get good quality signup. What is a good quality signup?

So back then we started to research on what it meant to be good. And the main thing that we found was just correlation, like watch activities. If a developer were correlated with future retention, and that was what we called ICP signup or high signup, however, the metric was actually, it was nonactive user. So it was a user of us that implemented Auth0 SDK and had got at least one signup through that SDK and the idea of that, now you would call that activated signup because it's an activation metric.

Back then we didn't know what activation was, so it was a different thing. Similarly, what we realised later is that the process was always the same. It was one developer logging into their accounts, then they added Twitter, Facebook, or something else, and they tried their same email, their same user with three connections with Facebook, with Twitter and password to see if it worked. If it did, they invited other people.

They also tried two more times and then they went more into production. So because we saw that path, we added that path as part of our metrics, which is like how can we get people to get that first non active user in the first day? How can we get them to get three in the first three days? How can we get them to invite somebody else and try it out in the first five days? And everything was just about that. It was about how do we optimise for this? Because if we know if we do this, they're going to go get activated and use it, and if they use it, some will pay, some will not. So we just started with that.

And then every experiment that we did, we tracked that Similarly, we built what we call the lead to revenue model, which literally showed conversion rates from how many visitors do we have, how many of them convert to signup, how many of those convert to activated signups, how many of those eventually get self-service? How many of them contact us? How many of them create opportunity, the opportunities, how much time does it take to close? Et cetera, et cetera, et cetera. So then based off of that, we could do planning on if we continue things as they are, where are we going to land, where are we going to hit? And when we saw that, we always planned one year and a half before.

So when we saw that next year we weren't going to hit our metrics by just growing how we were doing now, we would create what I would call bets. What could a bet could be? I bet that by trying things, we could increase the conversion from bid to sign up from 5% to 7%. So then we put that bet in and we saw what number it ended up and we guessed if we needed more bets or less.

So then by doing that, we actually started bets plans, which is like, okay, which are our big bets, which could increase a lot, but take a lot of work, which are our medium bets and small beds. And then for each of those beds, we were testing how things were working or not. In the beginning, we didn't do AB tests because we didn't have enough people to do AB tests. So we just tried things out and see how the metrics worked. Eventually, we did a lot of AB tests not to see a big increase because sometimes they weren't statistically significant.

By a lot of cases. We were doing a bit test just to make sure that metrics didn't go down so that if we thought it was better, we shipped it without seeing at least metrics don't work or something like that. But if I have to be honest, the main reason of why my team and I were obsessed with metrics was because of fear on the sense that I've never done marketing before, so I'm scared I don't know what the fuck to do, so I'm going to use metrics to try to see if something is working or not and improve it.

Based off of that, if you ask me now, my contrarian take now after doing it for a lot of years, is that I actually think that for growth being creative matters more than data. I use data because I was scared and sometimes I was scared of my creative ideas or the creative ideas of the team because it's things that other teams didn't do. So the only way that I found that I could try my crazy ideas and beat my fear was, okay, we're going to measure it and if it doesn't work, we'll kill it and we do something else. But if we works, we'll know, and then it gives me more confidence to try other stuff that is more unique or more creative maybe.

Adam DuVander: Sounds like having those levels of bets is important there too, right? Yeah. Some that take less work, some that you're more certain of.

Gonto: We always did something where for every quarter we started to plan number of bets, and what we were always thought is like, okay, of the big bets, it's going to take us five or six to make one work. So until then we'll make these small bets, which are changing a button, changing some things like small things and we'll increase conversion slightly while we wait for some of these big experiments to work.

Also, when we were AB testing, we always, for these big bets, we tried to do big swings. Why? Because for statistical significance, what matters is the samples that you get and the percentage difference between one or the other. So the biggest percentage change, for example, from a step-by-step onboarding to here's what you should do, go figure it out. That big percentage change made it be statistically significant with less people trying it out.

Matthew Revell: What advice would you give to yourself back then, now that you have all of this experience?

Gonto: I think the main advice that I would give would be don't be scared of using first principle thinking. Don't think that the other people, when they come and they tell you, you have to do ads, you have to do content, you have to do this. Just because they have experience doing it, it's the right thing. Sometimes maybe it's something that is different or more creative, even more, even though it's more scary, it's something that you should try together.

With that, I would say it's always better to be different than better. If you do the same as the rest, slightly better. Nobody will notice as much as if you try to do something different. And then the other thing I would share is that thinking and understanding the user at a deep level and understanding their habits, what they do day to day and why is the most important thing. Make sure that you spend time every week talking to developers if that's your target persona.

Adam DuVander: Perhaps the hardest thing, hardest advice of all that you've given here for a lot of the marketers listening, but maybe the most important thing. Exactly.

Matthew Revell: Hey Gonto, thanks so much for the time you've given us. Just tell us briefly where people can find you on the internet.

Gonto: So you can find me on Twitter. It's mgonto. I have dms open, so feel free to shoot me something there. You can also shoot me an email at [email protected]. So M at gon dot to. But to be honest, I'm better at Twitter on email, so if is on Twitter, likely, you'll get a faster answer. I'm starting a new podcast called Go To Market about our marketing take on what's happening on dev tools. Oh, sweet. Right.

Matthew Revell: Thank you.