In this episode of the Enterprise Monetization Podcast, our host Sandeep Jain sits down with Martin Gontovnikas to discuss how product lead growth led to the massive growth of auth0. In this episode they discuss how auth0’s monetization systems were able to scale with this growth and some advice for startups looking to follow a similar path.
Hi. Welcome to the 6th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders from monetization space that has CPQ and billing, so that you can learn about challenges, opportunities, and best practices in enterprise monetization. Today, I'm pleased to welcome our guest, Martin Gontovnikas, or short for Gonto. Gonto has a very unique profile that he is an engineer, turn market here, turn advisor and investor. Gonto was the sixth hire at auth0, with some of you when I was recently acquired by auth0 for a mere $6.5 billion. Gonto join them as a developer advocate. And eventually he became the leader of all the marketing and the growth team at auth0. Gonto left auth0 earlier this year to start Hypergrowth Partners, which is a sweat equity advisory firm that helps B2B startups to achieve hyper growth. With that, a very warm welcome to you, Gonto.
Thanks you for inviting.
Awesome. So before we go further into the depths of the monetization, do you want to share some quick fun fact about you to the audience?
Yeah, one thing that I'm, it's kind of crazy for me is that I did stand-up comedy when I was younger, when I was 16 years old. I was very, very shy. I didn't talk to people. And I wanted to start going out with more women to be honest. So I didn't know how to crack being less shy. And I figured out that if I did stand-up comedy, and I expose myself to talk to others and to be funny, just do that I was gonna be like, learn how to do a lot better. So I did two years of stand-up comedy, did some actually presentations in a theater. And after that, I actually I am much less shy. So I'm very happy to have done that.
That’s amazing. And where was that gone to? Was it in back in Argentina, or was it here?
Yeah, it was back in Argentina when I was basically in high school.
That's amazing. So maybe you're a stand-up comedian turn, engineer turn.
Exactly. I don't know. It wasn't that goal, as a stand-up comedian though.
Why did you stop it, like, do you still do that or with your friends or something?
I don't do that anymore. Like stand-up comedy is too much preparation. I don't like learning as much. So I've done it for a lot of years, but then I stopped. And I don't know why I stopped, I actually should have come back to it.
Okay, maybe there's a match for you there to go and experiment.
Exactly.
Cool. So here, we know that you started auth0 as a developer advocate. But I'm amazed by your journey there. And I think it's interesting for, I think people would love to know, like, why the shifts that happened in your career and why, and what's this backstory there?
Yeah, so I actually started programming and coding when I was very young. I was like 12, and I studied because my auntie was a Systems Engineer, and pick up like an ERP company here in Argentina. So I coded for a lot of years, I started with Visual Basic 6, which I feel a bit ashamed of. I then started Systems Engineering, and worked as an Engineer, Engineering Manager and architect for ten years maybe, like nine years, something like that. For the last few years, as I was doing that, I started to read more open source projects. Two of the open source projects that I built, became really, really popular. So I started to be invited to conferences around the world to speak about it and to companies to talk more about it. When that happened, I realized that it was more interesting and more fun to me to actually make the open-source repositories popular rather than them or building them myself. And that's what I always say that the dark side was calling me. From there, I actually remember that my ex-girlfriend, like finished a relationship with me. I had like a crisis of like, what the fuck do I want to do next? There was a guy and I really liked what he did. I actually Googled him. I found him on LinkedIn. He was doing developer evangelism. I didn't know what that was. So I went and Googled the term and I found the book by Chris Kaman. I stayed the entire night up, I've read the book, and I was like, Okay, this is what I want to do. So I started applying to companies then do the various interventions because he was a bit of what I was doing before like writing blog posts, speaking at conferences, but as a full time job. I interviewed in like Mozilla and a few others, and they ended up choosing to go to auth0 which was a very small company, that I was a sixth employee and the first marketing hire even though I was not a marketer, when I was there, I was basically writing the SDK’s, being the Sales Engineer in the call, writing the documentation, writing blog posts, speaking at conferences, and basically a bit of everything. And most of the signups because it was a product that developers could basically try out, most of the people who are registering and sign up or signing up in the product were developers. They eventually liked it, they contacted us, and they paid. So because I was bringing basically all of that through giving some of these talks, the CEO gave me the opportunity to lead the self-service team. Essentially, the theme was basically this idea of bringing signups. Signups will then use the platform-based service with a great card or sign up with enterprise, which now we call it as per the growth but because eight years ago, probably product led growth was not a thing, I think. So it was self-service. And from there that started, like, I started to try experimentation, it works. And eventually, I was given the opportunity to run out of the marketing and growth team at Atlassian. So when I left up to 7 years into the future, my team was 100 people. So it was a big, big team. I thought I like more, like smaller teams. I don't like the responsibilities of a 1000 company, People Company. So that's why now I'm working on Hypergrowth partners and doing advice on growth and marketing to other companies who are at a similar stage that I went through the entire journey with we don't see them.
I see. We'll go to your ARR’s journey in a second. But at Hypergrowth partners do you work with like startups, do you have any preference as to what kind of…?
Yeah, we usually look so we look for companies that have found product market fit. And what they want now is to scale their go to market efforts with a low CAC so we are low customer acquisition costs. There's no easy way to find product market fit. So what we usually do is we look for startups who are at least a 2 million of ARR, approximately up to something like 60 or 80 million. And we work closely together to do an audit first in the company, we talk to prospects, we talk to customers, we talk to the team, we look at their marketing technology stack, we then do better with them in the go to market strategy, set up what are the KPIs and the themes that we think that they should have, and then run experiments using our experimentation framework to drive that Hypergrowth within your customer acquisition cost. So usually, I would say they are CDSA or V Company, the minimum that we will look because see, that it’s a bit too early for us. Because we can advise, but we do not help with execution. So we expect a marketing team to be there to execute on some of the strategies and things that we talk about. What's different about us is that we do not charge cash, we charge equity to the companies that we help them, which is where we say you're like BC of time and knowledge. So we'll put money and will invest 5 to 10 hours a week in your startup, but you're gonna pay us equity in exchange. And that way we have steam the game to help you succeed.
That's amazing, Gonto. Besides your detailed explanation, I like the specificity of the things that you talked about to love this. So let's go back to auth0. So the first thing is, what is your thought about hiring, you said you're the 6th hire, but you're not writing third, but you're the developer evangelist. So what's your thoughts about that, like companies would think at that stage, I need to hire a Front End Engineer or a Back End Engineer? Nobody thinks about hiring a developer evangelist so early. So could you talk about that?
Yeah, I think that was actually a very good call from Matthias And Kenny are the two co-founders of auth0, like they already had the product, the first version of the product mostly built at that stage, because the other five hires were all engineers and one designer, basically. So he wants to continue hiring engineers. But at the same time, they didn't want to continue building the product without knowing if developers cared about it or not. And what it meant, when I showed him that there was only one local market strategy that was already made, which was that they were sure Kenny and Matthias that they wanted developers to be the users of the product to try it out and to sell to them if they enjoyed the product. And if that's the decision that I actually do think that hiring a developer relations as the first marketing hire makes sense, because I'm gonna be the one who are going to be creating the community and creating awareness through developers. And then in the beginning, we were getting a lot of feedback on things on the blog that didn't work out or what didn't great, etc. And that was sort of the conduit that was getting some of the feedback from the community and then feeding it back to the two founders and engineering team to fix it. So that also helped a lot with product development in the beginning as well.
I'm actually more interested in talking about the developer evangelism, and we'll talk about that later in the podcast. But let's put the focus on why we are here today, which is Quote-to-Cash. So can you talk about when you started the self-serve thing at auth0, and this was eight years ago. And if you can compare this with right now, like, what are the challenges companies will face when they're thinking about this? Could you help us with that?
Like we have so many challenges, I would say in the beginning. So the first thing was, we wanted to make sure that developers were aware and knew about, obviously, so our first challenge is we're about acquisition awareness, I would say. So our focus was on bringing value to developers, but writing good quality content on how to implement authentication. What is a refresh token, JSON web token, I have multiple terms that are very technical and authentication or security related? The other thing we do a lot in the beginning was, we bet a lot as well on it communities. So Angular JS, which is a front end framework was just starting, it was a 0.6 version. And I was personally pretty sure that I was going to explore MBB. So what we did, for example, was we went to every conference in the world about Angular JS. And it wasn't only because of providing value to the listeners, it was only because was also because we create the relationship with the speakers, because we sell them everywhere in the world, and we drink beers or wine with them, they then started to share our content, because it was good quality content. And then Angular community, we became the thought leaders, everybody was coming to us to ask us questions, all authentication. And what I found was important was being genuine. Meaning if somebody came and told me, Hey, I went out on authentication with Twitter, and Facebook, should I use auth0? And I was like only if that makes no sense. Like you should use it if you want multi-factor or this other thing, or whatever. And that started to create trust in the community. So in the beginning, that community was the one that was bringing us a lot of people to the content. And those that were intrigued afterwards, and then signing up to try auth0. So in the beginning, there were a lot of challenges more related to that than anything else, I would say. A challenge a bit later on was activation. So now we have developers who are coming to the product. But in the first day, we were dropping 95% of them, and only a few were staying. And that was because it was hard to understand the product. So we also focused a lot in the beginning on okay, how can we make the onboarding easier for developers? So they understand what's going on? How do we make it so that if the person who signed up it's not a developer, they follow another path? Because it doesn't make sense. And we also started to think about how do we sell to them, because at this point, the only way we're selling these developers liked it, they then click on talk to sales, and they were coming to us inbound, they was the founders closing the leads in the beginning. So we started that hiring our first inbound like sales account executives, who were basically closing deals, and we were getting through talk to sales. And we were not reaching out to developers at all. And we actually got to 20 million in ARR by doing this basically, we didn't do anything else. We didn't have any more sales rather than inbound sales, and waiting for people to raise their hands when they needed help for example.
So this 20 million ARR, were people buying to credit cards, or was it all sales done through salespeople inside sales?
There were people buying with credit card, I would say, it was maybe 10% of the revenue, 90% was through sides. But the difference was that our sales team did not contact them, didn't contact any sign up. And we were basically just getting people to try the products, use it, setting it up in their app, and then clicking into to say, Hey, I've implemented this in a big project. I like it. We want to explore using it for our full use case, and we talk. So there was still a sales process where like, I'm the executive was demoing it for their use case, they said engineer was building a PLC or doing a whiteboard session to showing how they could implement it. But the sales side, he was really short. He was like, between usually was three months or under three months, because they already tried it. They already implemented it. And it was more about making sure the work for their specific use case at scale.
Understood, and, Gonto, right now, if somebody's thinking about that sales motion, are the tools in place where people can do that easily or do you think it's there is some friction that people can expect there, and why?
Yeah. Regarding the tooling, I think, for us what was hard in the beginning was one, like getting people to raise their hand and then come to us like was easy. Of course they were like this that just raising their hand. But in advance, we started to think about what if they don't raise their hand and they need a little bit like a small push, for example. So some of the things we did in the beginning was, okay, we have predictive scoring to know which of these people are using the product, and we can predict they're going to become an opportunity. So for that, for example, we ended up building it ourselves with an algorithm called Random Forests. So our data been built it. But there's a lot of tools like MadKudu or Infer that I think are amazing, actually building some of the scores for you, and then helping you who you want to reach out and why. We've got intercom, for example, for sending emails, but then we had Salesforce, our CRM, and it was very hard to set up like tasks in Salesforce or for people to do something for an SDR or the salesperson, if somebody had a high score or something similar. So we broke DB, and it was all manually in the beginning. And we ended up switching to Marketo, which I personally deeply hate. But he just had a really good integration with Salesforce and made it really easy to actually flow leads with a high score and similar to other places. We used to do that workouts a lot. And I actually think that was a really good decision when using redshift. But there's others like snowflake, but that was our source of truth. And that was actually John Casey's the CEOs decision. And I think he made a fantastic call there, where that has all of the information and you use that to send information to Marketo, to Salesforce to intercom to whatever it is, so that when we switch to someone, we share information between the tools, it made it so much easier to actually flow the information and flow that leads from one place to another.
Did I hear you sit down to that your source of truth for leads on the self-serve, and enterprise was one system, which was redshift? Is that what you said?
Yeah, all of the things were in redshift, like literally everything was going directly to Data Warehouse. And then from Data Warehouse, we were sending it to a Marketo or goes a Salesforce or something similar. Plus, you set the source of truth where we saved all of the leads, information was always in the Data Warehouse.
This is a very interesting, you mentioned that Gonto, because I've talked to several people who do this Seltzer and enterprise sales, and half of the things are sitting in Marketo and half of the things are in Salesforce. And slack there is Gonto sitting in in your Seltzer, and then Gonto in Salesforce is the same, Gonto is a different. And so there's a lead, they're trying to understand is that the same lead or not, versus figuring out is this lead going to convert into an account? So it's very interesting. You have the single source of truth, which most companies don't. So when you left auth0, what does your Quote-to-Cash stack look like? So which is your like, give several channels, I suppose. So you had self-serve, you have enterprise sales, I don't know if partners were selling auth0 or not.
We were in them, when I left, yes, we have partners selling auth0 as well.
Yeah. How does this whole system look like? So is it still redshift is your single source of truth?
So redshift was still a single source of truth. But we were migrating when I left to snowflake, which is another database, but still, it's a data warehouse. So it's similar. What do you think Marketo for marketing automation, who were using Salesforce for the CRM, we call outreach for the sequences that were being sent by the STRs on emails and phone calls and stuff like that, using 6sense for Account Based Marketing, understanding who was coming to our site, and when. We were using clear leads to do reverse GeoIP address on host coming even if they didn't enter their email. And we're also using it to enhance the information that we were getting from them as well to then see if we could reach out or do something similar. We were also doing using Optimizely for both AV testing on their website, as well as website personalization, where we were personalizing the content based on what they were using, who were using actually a custom made CMS because content folding didn't work well for us. And we didn't like, we ended up doing something ourselves, I would have loved to use something different. The website front end was also custom made, but before I left, I wanted to switch to workflow, which is like a no gold version for marketing websites. I'm a big fan of workflow. We weren't able to switch in the end. And then we had a lot of random tools that we use for specific things, like funnel beam to basically get information for ABM leads on specific categories of information. We wanted to see which companies we were going to target first and which ones later, for example, but I think that was our main stack. We also have heap for analytics, which we will be sending the data there from the website as well as from the data warehouse and I think that's it. Those were like their main things.
What was the function management? If I'm buying auth0 from the web, there are probably different flavors, so what system has the knowledge on, what flavor of subscription people are buying?
So what subscription people have was all custom made, and it was save in the data warehouse, similarly, in the source of truth that I was saying. So it was all in redshift. For the payments with the credit card, we were using stripe. So that was just stripe, for your typical payments, it was something else. But our infrastructure for billing specifically was on custom built, and it was connected through our pricing page, as well as like the dashboard, the reading page, as well, and all of its data ended in the data warehouse.
Understood. And when people are connecting with you and say, I need a deal or give me a cord on auth0, I have like 1000 employees or whatever. Was there a system which is the CPQ that your salespeople were using, was it like Salesforce, or was it something else?
There was the CPQ, I honestly don't know which ones we were using.
Understood. Would you know, what sort of the invoicing thing that people were using internally at auth0? Like what is the system that was generating invoices?
No, I don't know, either. I know that before self-service it was stripe. So stripe was generating invoices as well. But then for the contracts, what actually do know, we were using intact for most of the accounting thing. So I probably guess we were using intact for invoices as well.
Sandeep Jain: Understood, and what are the currencies and number of SKU’s that auth0 was transacting in?
So the main value metric was active users. So how many of your users were logging in a given month that was the main metric. We then found the multiple plans that have different features like one has authentic factor or another one, enterprise Single Sign On or stuff like that? And what that changed is, what is the price of our value matrix, or what was the price of that active user? And then we have enterprise add-ons, where additional things that you would add on top of the plan. And we had like maybe six, I would say, additional SKU’s. So it was a bit complex doing all of that together for doing the quotes. We also have volume discounts. So it was a bit of a mess.
Understood. And what currencies were you transacting? Was it like multiple currencies, or was it few?
For currencies on self-service, it was always converted to dollars. And the same was what we did for enterprise contracts, like everything was eventually converted to dollars when we were getting it. But we have actually, we had like 45% of the customers in the US, but we kind of redistribution both in Europe and in APAC, compared to other startups. So we were like doing the quotes in a local currency. But then when we got into our bank basically was converted to US dollars.
Understood. In fact, a lot of companies that I speak with, they end up building their own billing system, which is what seems like you guys did, but it does not scale. And then they a big public company we have spoken with, they have roughly 140 engineers working just on that billing system. So it's not 10. It's not 14, it's 140. So what…?
For us, we actually had two teams working on their billing infrastructure, both on the pricing page on the other one, so between engineers, Product Managers and designers, they were maybe, I would say 18 people, or something like that working on it.
Interesting. And the company I'm talking about they have a revenue of 1.5, close to $1.5 billion in revenue. This is a scale thing. So if there is a city's a CEO, who is thinking about our CTO, thinking about monetization for their company, and they know their customers can come from self-serve, or this maybe direct sales motion? Do you have any recommendation on how should they think about their structuring, their monetization stack for like for good growth?
They do both bottoms up and top down, or they are the question if they, if you are, if they are trying to understand whether they should do bottoms up or top down first?
Actually, if they know that they have to do both. So it seems that if you're in one of the swim lanes, the choices of the systems are relatively clear. But the problem happens when you start thinking a blended. And you talked about one issue, which was lead management, in your case, it was one system of truth. But if your monetization is spread across two different systems of truth, it will be hard to move customers along that. So do you have any suggestions on how people should think about structuring this?
Yeah, like the main suggestion is related to what we talked about before, which is have a data warehouse which is the source of truth like that's literally what had that in there with every account, we can their subscription model like was it stripe or was it enterprise, as we called it. And they are, we also knew, what was the plan that they were using? So if they moved from stripe to enterprise, for example, we would change that in the data warehouse through an internal tool that we built, that the finance team was able to use, and that made things a lot more simpler for us. Otherwise, it would have been hell.
Interesting. And Gonto, monetization today spans across different teams like engineering, you’re in marketing and growth. How should you think about structuring this monetization teams like considering it's a multi-function task?
Yeah, I'm personally a big fan of cross-functional teams. So I think at cross-functional teams for this is something that would make sense. So, when I would think about it is you have a team that has engineers, designers, and a product manager, who are basically responsible for not only implementing the UI on the backend and for how much to pay either self-service or enterprise as well. And as part of that team, I will have embracing the pricing spreadsheets, or the pricing manager, who's also thinking about what are their skills? How do we implement them? So I think that's coming one thing that as all of that makes sense, in our case, the people that were part of a team reporting in two different areas. So that team had some engineers from marketing, were working on the pricing page, some engineers from products who are working on the dashboard, we got designers from both marketing and the products were editing things, we had the pricing manager, who was the one who was looking at these tools, was looking at what's working, what's not working. I had someone starting in marketing in my team, and then eventually moved to product and report it to product. But I think having a cross functional team that works together, and their sole focus is that even if they are from multiple teams, but they are one unit is the best way to make sure that there are no silos and that everything is consistent.
Interesting, Gonto, shifting gears a little bit. What do you think about usage based billing? A lot of companies that we speak with, have are thinking about doing usage based like earlier, it was one time, then it was subscriptions. And then are people experimenting with how the usage thing looks like? Do you have any thoughts on how companies should think about it (a) and (b) from an implementation perspective, would they face some challenges there?
Yeah. So to me being has to be related to what your aha moment metric is. And what your north star metric is, and what I mean by that is, for example, for our CEO, we had to figure out okay, what is the aha moment? And for our CEO, the aha moment was when they had their first user logins through their application. So with the SDK implemented, and they were getting like an authenticated token in return, that was like, Oh, wow. And then retention for us was 14 users logging in through the app in the first, like every month basically. And what that meant is that they were doing that they were going to stay with us for 18 months. So that we did a study actually of looking for correlation between which metric in the platform correlated higher to both long term retention in the product, as well as to opportunity creation and closing. So from a sales perspective.
That's the Random Forest thing that you talked about earlier, that you guys pulled.
That's the one?
You talked about Random Forest algorithm, the prediction, was that the thing that did this correlation?
It wasn't. So the Random Forest was more of like exploring the, we were using for leads, it was just an easy correlation on looping again, like we first started with qualitative interviews. And they're telling, what was the aha moment? And why do they care? They gave us like eight options. For those eight options we saw, okay, how many people who got into that in the first seven days ended up staying with us for eight months, or ended up paying, and that was the correlation coefficient. So, once we looked for the highest correlation coefficient, which had to be higher than 80% for us, and for us, it was the active users. So, once we have that, I think pricing has to be correlated with that. So if you've got one metric, that is the metric that is basically driving both long term retention, as well as higher likelihood of creating an opportunity, that is a metric you should charge for, because that's basically is the way that you're adding value to your customer. In our case, it was active users, which again, what's important about it is when we built it, nobody was talking about active users like our competitor back then which was Octa was charging for registered users. So how many users in total, like signed up to your app, what we realize is that signing up makes no sense because it has no value to the customer. It's about what users are logging in every month to that app, if they don't log in, they don't get value. So once we decided that, that was like, Okay, this has to be our pricing metric, because it's about the value. And to me, that's the main thing I will always think about, it doesn't matter if its usage base, if it sits based, if it subscription base, it means, what is the one metric that the customer, the more value that they get, the bigger it will increase. And that's the metric I think you should pick for setting a pricing strategy.
That's very interesting that you talk about linking your monetization to the AHA metric. For the Product-Led Growth companies, it seems so simple, but then it's so complex, when you get into the details, you forget about that. So appreciate. But have you heard any challenges, let's say if that metric comes around to be usage, which is a very variable way of pricing. I mean, you could have bands like 1-50 users, it's that, 50-200 it's that, but if it is more of a real time usage. Do you have any thoughts on like any? Have you seen companies that are facing challenges doing usage based billing?
So for us on these, actually, the biggest challenge that we had was understanding, what was an active user, like how exactly we counted. So for example, somebody is trying to login. And they login directly with Facebook that is an active user. But let's say somebody is trying to login, and they click on Facebook, they login, and that works. But the second step is they need to do multi-factor. So they now get an SMS in their phone. They don't get it and they don't finish the login, that comes as an active user, because we lock them in and they didn't get through security or not. What does it mean? Why? So for us, the challenge was defining exactly what an active user is, how it works, and making sure that we were always counting it in the correct way in the data warehouse, because if we're using that to charge our customers, it has to be predictive, it has to be always the same and it has to be clearly defined. And to be honest, in the early days, it wasn't clearly defined. So it was a bit of a mess, because we weren't thinking about okay, we needed with a lot of manual work to make sure that we were charging customers always correctly. That was in the very, very early days. Eventually, of course, we fix that. And then it was automated. But that was something that was a big challenge for us on how do we do this usage based billing.
Understood. And Gonto, for implementing auth0, did you see any customer issues on billing and quoting? Do you remember if it was a big thing, or was it like…?
The main issue with other on being a biggest one we had was without self-service with credit cards. And when there credit card expired, Stripe was trying the credit card for like three or four times and eventually stopped trying. So we actually for a couple of years, we had people that were using the account for free for and we didn't know. And once we figured it out, of course, we're not gonna charge them all of the time that we didn't, because we fucked up. So we fixed it. And we started to automate, hey, your credit card is wrong, you need to fix it. But that was like a big challenge for us on how we do billing when credit card expired, or there was another issue with the credit card that didn't raise up to our concerns. That was one. And the other one was just in the beginning, we didn't have like an accounts receivable person that was focusing on collecting money from the contracts. And when we didn't have, that companies were taking a lot of time to send money, and it just took forever. So we need to actually people to focus on the accounts receivable part as well. So we made sure that people were paying.
This is when they are not paying through credit card. But there are paying through an invoice that is interesting. And related to that, is there an amount of money that people are comfortable putting on their credit card versus, you know, they want to put this and ACH or an invoice, is there a magic number or range?
I don't think there's a magic number. And for us, we actually packed it. But I can give you example of Twilio as well. So for us, what we wanted is when the customer was paying more than $20,000 a year, we wanted to build a relationship with them. So what that meant is we were not going to allow them to base and service more than $20,000 a year. Because in that case, we want to include an account manager in the accounts who can help them and do a bit of help and make sure that they are being happy. So we actually kept it but people wanted to pay more. And that's an example that to me is fascinating is Twilio. And they had customers who are paying 200K a year or 300K a year with just credit card and talking to literally nobody. And that worked for them. I was actually, I would be excited to try out if that would have happened in auth0 or not. But in the end, we can make that change. But it was very interesting how it worked for Twilio.
So what you're saying is that people and this is news to me, by the way, personally, that people aren't comfortable paying. And this is B2B customers we're talking about. So it's not like individual consumers that don't pay more than $20,000, $200,000 on their company credit cards for a transaction?
Yeah, it was crazy to me too. But at least in Twilio, that happened often.
Okay, because the most challenges that I've heard is that if the transaction is more than $5000 or $10,000, their companies don't allow to put that much amount on the company credit card. So there is a need to do self-service quote on the web. Like people don't want to talk to a salesperson. They say just give me a code. It's $50,000. And I need to raise an invoice and my company will pay you, but I want to talk to the salesperson because that's I know I want this.
That might make sense. I think it depends on the company. For us again, we didn’t allow people to pay more than 20K. We did a bunch of people who were paying 20K with the credit card at least.
That's interesting. Shifting gears a bit Gonto. Do you see or hear about AI, ML, in this marketing Quote-to-Cash world? Do you have any opinions on that? How intelligence looks like, you were using intelligence in auth0, the Random Forests, the Correlation Coefficient? Any interesting things that you think are being done or should be done?
What's interesting about AI is personalization, like everyone is doing personalization. What's the next page that they should see? What is the next blog post they should reading? What is the next documentation page that they should read? So they don't have problems, or when do they reach out to them? I think all of that which is personalization, I think it's a table stakes. Now when most companies should start thinking about that are these Random Forests and a predictive scoring as well from AI and ML. But to me a lot of AI and ML is gonna come with like, to better act for people who you still don't have any money. So you don't have a lead yet. You don't know who they are. But still you can get lot of things of them based on where do they come from? What patiently see, how much time do they stay? So for example, we were guessing on their websites based on what they saw how much time they stay there, if they were a developer or not, we didn't even ask them, we didn't even know it locally work. But we use that information to then market them differently. So I think looking at behavior and getting stuff from people, before they enter your email is something that I'm gonna see, I think we're gonna see a lot more. And similarly getting intense data. So for example, you get data from G2, or other services, even before you have any information from you. And using that for personalization on the website. And what you are going to be able to do, I think is another thing that I think most companies are gonna start using sooner.
That's interesting. Related to that, do you have any suggestions on like, companies always have a variation of good, better, best, and there are customers and of course, each category. There is a lot of value in moving customers, who are existing customers from are upgrading them to the next level. And companies struggle with how do I figure out like, who are these users in the basic category who can be upgraded to the next one? Because these customers are already with you. Do you have any suggestions on figuring out these, I don't know, growth potential customers?
For those, I also believe in like predictive scoring, like we did the same thing that we did on who is going to become an opportunity on it, who is gonna expand from self-service to paying a balance, and who's gonna expand between that enterprise paying accounts. And we use that score, who also send to non-executives to account managers to reach out. So for example, when we collect high score from self-service, we started to call account executives or SDRs reach out to them like, hey, we're seeing that your usage is increasing in these units and more help on implementing these like, and stuff like that, just trying to become helpful. But I think that on that similarly, like predicting scoring on a specific metric is a very easy way to do the good, better grades. And as I said, you can use something like MadKudu or Infer who also support that as well.
Got it. And Gonto, I want to touch on a little bit of developer evangelism. I think we talked about initially that you went to different conferences and built relationships with the speakers. Any I thought that was very interesting insight, by the way. Any tricks that you want to share with the audience on the companies that are thinking about building developer communities? I'll tell you what I have heard, people think about should I go on Twitch? Do I create a Stack Overflow on my website? What's should I? Should I sponsor conferences? Like what's the way to do to do this smartly? What are the hacks there? Could you share some actions that work or that do not work? Could you share things that don’t work as well as work? I don't know if there is things that you can put in my bucket. But I would love to know.
Yeah, so I think like, first of all, one thing to understand is like, not all developers are equal, like developers are different. And it will depend on who you're targeting. So I don't think there's one silver bullet or one thing that you should do Stack Overflow or slack or discord, or something like that. What I'm personally a big fan of is like, think about what is the service that you're reading? And then based off of that, start doing interviews to the target developer that you care about, and ask them about how do they learn in our case? How do they learn all indication? What do you want to learn on? Where do you go, what apps to use? And the strategy I think will come from that. So to give you an idea for us, when we interview developers, about whether they want to learn how to level authentication, everybody answered the same thing, which was, I don't give a shit about authentication, I don't want to learn about it, it's boring. I will only look for authentication, if I'm stuck when I need to implement it, and I will Google how to get unstuck. So based off of that our strategy was content marketing, and it was how to guides or how to implement authentication with React, or with other technologies or something like that. But that was the main thing for us, because of that insights. Our developers that were the front end developers, in our case for implementing litigation, were saying that they spent a lot of time in Twitter, following other people. So again, we tried to go to the conferences where the people, they were following what they actually do with a relationship, and they shared some of our contents. But it all came from some of this research. And everything that we tried, it was not part of this research was like didn't work at all. So for example, when we switched from developers to Product Managers, when we didn't switch, when we also targeted Product Managers, we felt like okay, let's do a same, let's write blog posts about like, How to Guides and stuff like that? And they were all like a complete failure. So we went back to interview Product Managers, and account managers we targeted was from global 2000 companies, and they have specific sizes of teams. So what we learned is that Product Managers from smaller startups were reading blog posts, these Product Managers were not reading blog posts, and they weren't growing to make their product confidence or product and media to learn or reading from analysts. So then, okay, that's our strategy. We need to work to product and we do sponsored events. But it all came from these interviews, I don't think there is a silver bullet, except for actually talking to your audience to understand what they do and how they learn about data. And why do they care, and then create a spreadsheet based off that.
I love the specificity of it again, Gonto. But tell me this thing, did you yourself were doing interviews? Was your team doing interviews? Did you hire somebody to do the interviews for you, because I see both models, I don't know if you have any opinion on that?
In the beginning, I was doing them because I was the only person in the team. So I was a solo person doing the interviews. When we targeted the Product Managers, we were much bigger back then, I didn't do any of the interviews. It was like people on my team in their growth team, doing the interviews and writing the insights based off of that, but it was always outside. I personally believe it's better to ask the questions ourselves. And it's only because of one reason. I only come three questions, like the three questions that I mentioned. But then when I start talking, when they say something, it gives me other questions and 100 ideas. And if somebody else does it for me, I cannot do that. And the biggest value came from the random questions that I asked when I was doing the interviews.
This is very fascinating. You mentioned that because I also from that same school of thought, interesting thing comes, you know, in a regular conversation, like I was not expecting us to talk about the leper evangelism in this podcast, but it just so happens to be talking about it right now.
Exactly. I'm a big believer in serendipity and randomness, because that's the world we live in for random.
Yeah. And I've seen the companies, you know, they somewhat struggle between you know, as I said, external agency, they have UX researchers. They have Product Managers, and their growth people and the trend of struggle, like who's going to talk to this person? And of course, this person cannot talk to the four of the entities. So that's interesting.
I think it depends in that case on it, what are you trying to solve? If it's a go to market strategy is broad, if it's a specific feature, how it works is product management, but they're getting everybody to talk to one person. And usually what I've seen similarly to what you said is, the four people who want to talk to them, so then nobody talks to them, which is fantastic solution.
Interesting. Gonto, this was super interesting conversation. I don't know if you have any summary thoughts on this bottom up and top down sales motion, because this is something that's very close to the B2B startups right now, like everybody wants to do Product-Led Growth. And but there are some things where I think Product-Led Growth I personally think does not apply well. But any closing thoughts on that?
Like, it's two main things to me about product led growth. One is the user, or two or three, the user must be willing to try things out, and to try a product. There are some users that are more likely to try things out others that do not. So if they do not try things out, of course, it's not gonna work. Second, that they should see value with a small implementation. So for example, with auth0, you could implement it for one small things, or for one more small team, and it worked, you didn't have to implement it to all of the applications to get value from it. If you need to implement something across the entire corporation to add value that is not like product growth, you're not gonna do Product-Led-Growth, you have to have a unit of value with 1 2 3 4, not more than that, if they do not get value there, I don't think it makes sense to do Product-Led Growth. And the other one is, you can use to do Product-Led Growth, if the person who is the user has enough power in the organization where they will be able to talk and try to convince the decision maker or the buyer, or if the user is the same as the buyer, usually user is not the buyer. And if that's the case, they should at least be able to influence the efficient, if they don't have influence power. Again, I don't think Product-Led Growth makes sense.
Awesome. This is a great way to sort of end our conversation Gonto, but before we let you go, would you have any recommendation on a resource like a book or a podcast or a blog that you'd like to recommend to the audience?
So I always recommend the same book. My favorite book is “Thinking Fast and Slow”. Like to me, it helps you understand how our brains think. And everything we do is related to that. So if you understand how the brain works, then you are much better at making sure what to say to people and why to get the message across. So by far at least for me, Thinking Fast and Slow has been one of the best books that I've read in my life.
Awesome. Hey, with that, thank you again, Gonto, for your time. This was a very fascinating conversation.
Thank you for inviting.
