Lessons From Building Two $5 Billion+ Products with Shiven Ramji, Auth0

We hit the sweet spot of developer experience and so I think these are the sort of the ingredients you got to make sure if you want to deliver a great developer experience. I keep reminding my teams every day, make sure it's easy to get started, make sure it's easy to use, make sure it help, it's easy to get help, and make it easy to hack.

I need some traction. You need some traction. Let's get some traction.

Hey, what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over a hundred thousand people just like yourself on a mission to help you get the methods, the money and and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more, this episode is brought to you by Boast AI. Each year the US and Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast AI software to maximize cashback. Check out B oast AI. This episode is also brought to you by Launch Academy and an international tech hub that provides mentorship, resources, network and the environment for entrepreneurs to launch, fund and grow their startups. Since 2012, Launch Academy has incubated over 6,000 entrepreneurs, of which 300 have grown their startups past Seed and Series A and have collectively raised over $1.2 billion in funding. To learn more about Launch Academy's programs, check out link launchacademy ca I'm super.

Excited for today's session because building a developer product is probably one of the hardest things, hardest kinds of startups to build because you're selling to people who don't really hold the budget. And I couldn't find a better speaker than Shiv here because he's built two multibillion dollar developer products, DigitalOcean and Auth0. DigitalOcean IPO'd at 5 billion. Auth0 was recently acquired for six and a half billion. It is. It's like a unicorn within a unic in itself. Like how do you do this? Build developer products. And he's going to tell us all about how he's done that. Leveraging two different models, product led and sales led previously Shiv was prior to DigitalOcean he was in leadership positions at global brands like Amazon, NBC and the Nielsen Company. Shiv, thanks for joining us at Traction. Give us your backstory.

Yeah, backstory is I actually started as a, as an engineer so developer products are close. Were closer to my heart in that you know I've built software before, been through the pain and so some of the affinity to building developer products came naturally but I didn't. That's not where I started actually the backstories I've sh. Moved around different industries and have held different roles. Everything from biz, dev, software, hardware and even marketing, project management, program management and ran big data teams also. So I'd done a lot of these things and been very fortunate to have worked at large companies but also smaller growth stage. Smaller and growth stage companies just run the gamut in terms of the experience and, and I think what right about the time When I joined DigitalOcean I was just really impressed by how they catered to developers and especially the motor on community and so that just really drew me in and then I haven't looked back ever since. So I spent a few years there and then after that got into ODD zero Wheel which also had a really amazing developer product and community. So it was a no brainer fun fact like my actual professional career started. One of the first software projects that I worked on was building a single sign on for the field operations team. When the founders Matthias and Eugenia said hey we have this identity as a service, I was like you don't have to sell me, I get it. Because it was a pain for me to build it myself. So that's, that's a backstory and that's how I, I got to ODD zero and just really lucky that both exits happened literally in the same month, two weeks apart could have predicted that. And it's just timing of the market.

And everything else played out lots of commonality too. Like I'm a big believer in community. Like I always say, fall in love with your customer and make them successful beyond your product or service. If you build a community you won't be a commodity. We know Farhan VP Engine Shopify. In my previous company that failed Digital Ocean was our first paying customer and not too long ago I had Carol Cooper from Live intent on our show as well.

Spent some time there too. So we know a lot of people in common now.

Great journey. But what, what actually made you go to DigitalOcean and take that job? Because it's different kind of company to Live Intent Yeah, very different.

I'd spend a lot of time in. Yeah. So if you go back, I done media research, market research, then moved into building advertising technology. So I was in the very early days of building Amazon's ad business which is Now I think 15 or 17 billion dollars run rate. So build cortech there and then moved into email and martech and so I'd done a bit of that and it was a time for change and I knew some people at DigitalOcean that had worked for me. So one of the PMs said hey, we're looking for a head of product here, I think you'd be great for it. And I was like wait a minute, I, I haven't built anything and I've consumed cloud products because we, we built a lot of the Amazon ED technology on aws but I had not built products for developers and, but they said you should still chat to the founders and the CTO and see if this works. And, and sure enough that I just fell in love with the idea of like DigitalOcean specifically was very much a product led growth business and then gone to at the time 80 million 100 million plus in ARR with literally no salespeople. It was all self service. You come in free trial and then you convert to a paid customer and the product was really simple and easy to use. And so I think that was the hook for me which is looking at a product that scale and impact at the time also going to a startup that was an underdog to the large behemoth such as AWS and Microsoft this cool. If we can carve out a space here, wouldn't that be an amazing story? And sure enough the cloud is so big that there's going to be a few winners. And because DigitalOcean was really tailored to the developer audience, I think we were able to differentiate very nicely and put ourselves on the map in terms of outstanding cloud companies out there.

I think you made some great bets there and it's quite evident and you built some world changing products here. Let's shift gears to product led first. The most valuable companies of the past decade have been product led. If you look at everyone From Dropbox to DigitalOcean and Slack, if you look at the fastest growing companies on the stock market, they're all product led. How do you define product led? Give us the key traits for success in product led.

Yeah, so I think the key elements of always for product led there are a few things here to look for. I think first and foremost is you should be able to Try the product before you buy. So let's just look in the case of DigitalOcean free trial for 30 or 60 days up to a certain amount of usage. You could just try it out and if you don't like the product you can leave. But you could experience it firsthand. And the same is true even at odd zero because most developers we have a free developer tier so you can go create an account, set up an odd 010 and get an API and integrate in your app and you can see the login box powered by our service. So try before you buy is really important in that same light. Freemium models are also really helpful and there's this misconception of like product led growth is really for more like consumer like products and that's just not true because I'll give you an example. Like at odd zero there's a lot of developers from enterprise companies will come in, try the product, do a POC and they've already gotten value from the product. So it's so much easier for them to go advocate to your point earlier even if they didn't have the budget. But they have influence in the buying decision. And so they can show, not just tell, they can show that Here I've integr this login as a service and look, we don't have to worry about being an identity expert or worry about compliance and the like. And so I think that's been really important. So even for enterprise products this can work. Things like product onboarding, time to your first value or aha moment become really important because you don't, you're not relying on humans or sales teams, you're really relying on your product to do the to lend your customers and get them value right away. So I'd say product onboarding, product analytics became really, really important and important investments for product led companies. And with that as customers grow you have to pay attention to. Yeah, I'm sure you've heard about PQLs or product qualified leads we had those were like really famous at DigitalOcean. Like we knew that if you had combined the following three features we knew you were going to grow or if you had invited a certain number of users on your team or created teams, that was another indicator like yes, we know that this customer is going to expand with us, so that was good. And then we also invested in growth teams in both companies we have dedicated teams that are solely focused on when a customer comes to the marketing pages or WWW homepage and when they switch to trying the product they obsess on making sure that experience is, is useful. And so having a growth team really helps and this growth team then really it's all about continuous learning and sort of experiment because especially if you have a large audience or volume of users who are coming there, there is always a lot to, to test and learn. And so so I'd say those are really the big traits and maybe differences compared to other emotions and and there there's just a little bit of a misconception of product led companies won't embrace sales. And that's just not true. Ultimately you are selling might be in a self service fashion or in the case of Odd Zero, the interesting part was they did start in this product led growth motion. They were growing and then at some point they do switch to more of a paid plan. And at that point obviously the relationship is taken over by someone in our sales organization. So they can coexist. And that's the beauty of at least when I was there. And I know DigitalOcean is investing and it's changing, but they're changing their models too. But we were primarily product led I think in ODD Zero. We invested in some of the sales LED motions early on and I think that bet paid off quite well.

Definitely. I love the whole concept of PQL here. I say this funnily. In January I had Covid and I got pretty serious and then right around our fundraise happened, we got a lot of press and San Francisco Business Journal has covered my Covid story. So we got a lot of leads and I told my team all the leads are getting our PQLs and they're like no, they're not coming through the product, they're coming through the website. How are they PQLs? I'm like, they're pity qualified leads, not product qualified leads.

You just gave a different meaning to P in PQLs.

Now definitely in terms of PQL, can you walk us through what are some indicators to make a lead PQL and how do you drive that sort of volume?

Yeah. So I think this is where if you have a data team or a growth team, depending on what your configuration is, different companies might have a different setup. We really looked at, we did a lot of machine learning models to determine which of these leads or combination of leads were the biggest predictor of it being a qualified lead for us. And when you have, I'll give you an example at DigitalOcean on a monthly basis, if I remember correctly, like 32,000 new signups and so that's a pretty significant volume for you to play with. And we constantly looked at all of the signals around obviously if they had a business email or not, what did they do when they first signed up, what type of virtual machines they use? Did they set up a separate billing, did they set up their billing separately or added additional teams? And so we had a number of signals that went into our machine learning models and we would score these leads and then that's how we landed on. We knew we could predict that. Here are the leads that would actually give us that are actually worth pursuing. And remember in, in at least in DigitalOcean US worth pursuing wasn't somebody calling them necessarily. It was just, we just did better targeted emails. And your email drip campaigns fell, followed through nicely and really that's how they continue to expand and upgrade. So really well oiled machine from signup to lead capture to lead scoring to then acting on those leads via communications either in the application dashboard itself on the homepage or onto the on via email. Over time, obviously as we invested in customer success teams they would get this feed too. And the same model we've applied at odd zero where again once you sign up and once you start using the product, the number of applications that you are integrating would tell or the number of, or the types of features you're using would tell us that, you know, they're ready now to actually engage with the customer. And obviously you also did a lot of targeting communications. So it all really depends on the volume of data I think.

How did you drive that initial influx? Like how were like was there there's this sort of pirate R metrics where you acquire activate, then they retain, then they refer. Like how do you, how would you break down the metrics? And maybe starting with just driving that top of the funnel to sign up. What did you guys do?

This is where actually this is where community has been powerful in both scenarios. Let me start maybe with, with DigitalOcean. So one of the things, and I know we earlier were talking about community led products and like you create this mode at DigitalOcean. One of the things very early on the founders and invest in is in a team that wrote really very strong writers and who were building technical content. And so they created this, these technical articles that were really accessible to anybody. And so it was all free content that you could just search for like how to set up your lamp stack or how to configure Ubuntu version xyz. And it just became a place where everybody wanted to learn. And naturally once we had established a brand of here's where you go learn everything about cloud computing or virtual machines or DevOps. It was a natural place for them to say why don't I just try the product? It's so simple and easy. Right. So that was like a really big way where DigitalOcean captured significant traffic. So a big portion of the traffic that was coming on the top of the funnel was organic. It was not paid media or paid traffic. It was because somebody was searching for how do I set up lamp on lamp stack. And that's how we landed a lot of customers. So that's one example. And then if you look at with Auth0 it's a similar story which was writing a lot of articles about how do you configure saml, how do you apply the YDC standards and how do you do login. Frictionless logging, like what does passwordless mean? And and so again there we ended up building really large communities. In the case of, I think DigitalOcean then the number of unique visitors per month was really impressive. I think it was probably 3 to 4 million if I remember correctly or maybe even higher. And then, and at odd zero it was about a million uniques per month. So that's a pretty sizable audience that's coming to consume your, your content. So content was a really big part in solving the top of the funnel needs that, that we had let' sales.

Led or product led. So what was easier sales led like building a sales team or what you did at Digital Ocean? Because Auth0 also became a multibillion dollar company.

Yeah. So being a product person I'm a little bit biased or I was a little bit biased and believed like hey, let's just continue investing in product led growth and like we can continue to grow. But I think an odd zero was different. Now at Odd zero we had established a sales arm and team much earlier and I think have a very good relationship CRO who, you know, who came on early, very early on, set up teams to make sure that we could take all of, all of those leads and start building an outbound or at least it was mostly an inbound business but slowly approaching outbound, which is sometimes for some of these products you do need a salesperson to talk to the buyer. Right. So think of the free tier as, as, as, as influencing the, and the influencer of the purchase. And then us having a sales team, we could essentially talk to the buyer. So whether it was a CTO or a CISO because they probably cared about other things. Do you have auditing enabled? Are you Compliant? Do you have certain compliance certification? We want to go through an infosec agreement. So those were all things that were handled by the sales team. So I do think these can coexist and if you can strike a healthy balance, you can build a pretty healthy business. And just to share an example that at odd zero the growth rates were significantly faster. And the reason was because we had sales teams now engaging with large enterprises and so we're landing much larger logos and as some of these large logos can drive a pretty significant portion of your ARR growth. So that was, that was so two, two companies, two very different approaches. But I think at odds we're able to strike a good balance. And having a sales team really helps you go up market if you want to target enterprises. They're used to talking to somebody, they're used to asking a lot of questions, they're used to seeing other things we learn is that they want to see like a 12 month or 24 month roadmap. Right. Like a digital ocean. We were just like hey, we're talking to developers, they want this, we build it, we ship it. And I think at odd zero the approach was slightly different in that we had to think much more long term and, and then we also had to do I think having compliance, being able to answer compliance questions. And, and then I think the other difference is if you have a sales team you can own customer education much more closely. So, so there are quite a few advantages of having that and that really helped us because we could tell the story in a way that, that, that made sense and we had a feedback loop back into the product organization.

Definitely. And I think price pays plays a big part into that.

Right.

Depending on the size of the sort of customers you're going after now you're going to enterprise now. Auth0 being sales led, did you still have product led motions in there? Because starting with the developer, then seeing how it proliferates, then passing those pqls product qualified leads based on actions to the sales team to nurture. Is that how that flowed?

Yes, yes, that's how it works. Maybe a little bit of a nuance and clarification. Anybody can create an account like I said in the free tier. And then some customers were just happy because we have the developer and developer pro tiers. They were just happy with self service. So we do have a team that's really focused on our self service business which is also growing rapidly. And then we also nurture sent those product qualified leads and we also have a marketing team. So we had MQLs in this case also, that then essentially went to our adrs who then took those and started engaged with the customer. Yeah, that's exactly what we did.

Awesome. And then I had Jeff Lawson a few months ago and he talked about how all the investors thought they were crazy trying to sell to developers. What were the challenges actually? Or maybe folks like Twilio paved the way and AWS paved the way. Did you encounter any challenges trying to convert these developers to paying customers in both models?

Let's start with the first one. So at DigitalOcean, I think we had great success with what I call hobbyist developers. Right. So even though you worked at a big company, but you wanted to learn something about a new technology, let's say you want to learn something about Kubernetes, you could come up, spin up a virtual machine for $5, fairly easy. So we built a really big business to then have bring DigitalOcean to work. Like, hey, use it on your personal project where you're not using at work. I think the biggest challenges there were were mostly like, related to can your product handle like the enterprise requests? Do you have auditing? Can I do teams? Can I have single. Single sign on? Do you have certain compliance or can you support HIPAA needs? Do you have PCI compliance? You have ISO? There are all these compliance needs that initially we were blind to because we're like, no, no developer is asking us for are you PCA compliant? That's not something a developer drives because that's usually coming from the legal and compliance team. So that was a blind spot initially that we slowly started to address. So. So I think those were the types of challenges we ran into. The other thing was if you have a hobbyist website and let's say you went down for five, 10 minutes, you're not going to complain. Whatever my own personal blog or my, my hackathon project told good for a business, you can't have that. So reliability became a really big pain point and need and so invested a lot of time in, in building reliability. So I think those were some of the challenges that we, that we faced with ODD zero. I think it's been on the compliance side. We learned early that compliance was needed, so we started much earlier, although not early enough, I would argue. And I think brand building is also quite a bit of challenging. Right. Because we were at least when we were a smaller company, it's not very easy to break into larger companies because they're like, well, I don't know, are you going to be around if I build my authentication layer on you. What if you're not around from a few years? So those. So it took us a while to establish credibility, that we're well funded, we're going to be around and we're going to build a significant business. These early companies, Amazon, Twilio, Stripe 2 I would say have paved the way and so at least with ODD zero it was much easier because part of our pitch was just like you have Twilio for messaging, we are ODD zero for authentication or just like you have Stripe for payments, we are zero for authentication. So that association definitely helped and I think they did pave the way for many other companies that are thriving today.

I would say both these companies are hyper growth companies, right? Like growing really fast, leveraging the product and like just spreading with the weed or virus within the community and expanding the community. How do you build a hyper growth product? Can you or does it just happen?

I think in both parts scenarios when, when, when they were building it was not apparent honestly that, that they were going to grow at the rate they did and, and like in the early days of DigitalOcean like they would run out of server capacity so fast they could not rack enough servers fast enough in the different data centers. So it was like, you know, I remember the teams are working 247 to keep up with, with demand and remember when you're an early, earlier stage company you haven't thought about things like rate limiting and queuing customers because you've never thought about those problems so they can really overwhelm you. So when you're building that I don't think but I think as you're iterating and experimenting, I think looking backwards there were signs that hey, this is going to be a really high, fast growing product. And I think you can if you iterate and constantly experiment. And I think with all of these also timing matter, I don't know. Sometimes DigitalOcean worked out because AWS was already there and just not catering to the developer audience. So the timing was really good. And in the case of Auth0 I think customers had experience at least using a SaaS product for communications and payments and so authentication maybe was a natural next area. So I think timing does matter quite a bit. And then I think the big learning there though, at least in both scenarios for me, was that you couldn't start investing early enough in overall reliability and sort of your trust pillars. Right? So whether it's security, compliance, availability, disaster recovery, these are the things that when you're in hypergrowth mode you don't pay attention to. That can really, that can really hurt you later. So I think, I think you would know, like my term for this is products having extreme product market fit. An extreme product market fit is when you can't really tell why you're growing so fast. Right? It's like really weird, but, but you will know when that's happening to you. And so I think that's, that's something to look out for when you don't have enough metrics or insights why you're growing fast. You probably have hit extreme product market fit and obviously grow and ride the wave. But. But at some point you've got to figure out what's driving. And I think even like back in the earlier days of Slack, they had a very similar story, that the product was just growing so fast they didn't even know what was driving growth. So that's another case of this extreme product market fit.

What were some hooks for that level of virality at do? And then also auth0 or maybe they were separate.

No, there is some common themes there so I can tease out. So when you think about user experience, like you would say, why we all know today user experience is really important, although I can't emphasize that enough. And when in a typical company would ask what do you mean by a good user experience? And so the questions you have to answer, is the product easy to get started, is it easy to use and easy to get help? Now you take those. The same principles apply to a developer experience or developer product. But I think there's one more that I would add there, which is it easy to hack? Right? Because developers are problem solvers. So one of the things that both DigitalOcean allowed and even then Auth0 is that with DigitalOcean you could really do anything with your virtual machine, right? You could, you could build any kind of application, you could use any stack. And so it really allowed developers to iterate and try new things. And then with ODD zero, we built sort of our extensibility capability, which is we allowed developers to run custom code in the authentication pipeline. And so these were the reasons why I think we hit the sweet spot of developer experience. And so I think these are the sort of the ingredients you got to make sure if you want to deliver a great developer experience. I keep reminding my teams every day, make sure it's easy to get started, make sure it's easy to use, make sure it's easy to get help and make it easy to hack. Because there's no way we can think of all of the ways developers want to solve a problem and think of most of them but you want to give them the flexibility. So I think that was the secret there.

Definitely. And possibly also easier to share.

Yes, easier to share too. Yeah, I like that.

So I get asked you so what would you recommend for an early stage product led startup? Focus on ease speed of releasing features that are not but gives us more options to attract users and maybe make money or focus on sticky features that will improve user experience and retention.

I think in the early stage. I think in the early stage my recommendation is. And again I don't. There might be some nuance here at the stage and how many customers are adopting but usually you're optimizing for more experimentation and not less. And the only thing I would say is experiment quickly but make sure that these experiments are not expensive or draining. One of the things that, that I think you have to be mindful of especially if somebody's building. If you're a critical part of a, of a developer or customer's architecture you have to be mindful of if they build a dependency on your product and you decide I don't want to support this feature anymore. And if you have customers who have built some critical dependencies on that, I think deprecations can become really challenging. Again bigger issue if you're dealing with enterprise customers. Less so if you're with with SMBs or hobbyist developers. But I would say early stage you should optimize for trying a lot of things and quickly killing the things that don't work and build up your first extreme product market fit. Right. Like you should be really known for something amazing and then you can build around it. And this is true if like products like Slack, true of products like DigitalOcean true of Twilio, true of even Odd Zero which is we did this one thing really well, better than anyone else because then that's how the product helps you. You stand out and then you can go build out sort of retention and stickiness from there. That would be my approach to that.

Let's see, there was another question here. We're a product led chat and video and have thousands of developers on our free plan. Our inbound. Our model is 99% inbound. Most are using the free plan. Interesting to see you had a similar model on a free trial period. Then move to paid. I feel there's a massive opportunity for growth.

Right.

Would you give everyone notice of a move to paid? Like how do I think about that? Free to paid?

Yeah. Okay, so let me this is a very good question. I want to share a few insights here that will be really helpful. So let's start with first at DigitalOcean we did not have a free tier there, we had a free trial. And the reason is that DigitalOcean it was largely a usage based model, although the pricing said $5 a month. But ultimately it was about how much usage you have on your compute bounded by obviously the number of CPUs or STOR and certain amount of networking. And so in products like that, there can be quite a bit of abuse. Abuse at DigitalOcean. Like if a developer can just set up an app that can spam or that can hack and send massive DDoS attacks to other companies like you can, there's a big abuse factor there. So there, the free trial was a better way to ensure that we curbed a little bit of that, a little bit of that, that abuse. And yes, I actually led a pretty big pricing change there where we essentially change the number of resources you'd get for the same amount. And pricing changes are always tricky and difficult. You really have to spend your time understanding the impact to customers, the impact to your top line and your bottom line. Switching over to ODD zero there we have a free trial because we control the abuse factor significantly. There's only so much you can do with our free tier. And then what we did was we started segmenting certain features into paid plans. And so I think one, one thing that I would recommend in this case, this video company that has a lot of, you know, start thinking about pricing and packaging early on and figure out which are the features that make make sense to be in a paid tier. And like anytime you make a pricing change with a developer audience, there is going to be pain. But if you're authentic, if you're transparent about your changes and you give them enough advance notice and give them a path to, to a happy place, then I think you'll be fine. Because at the end of the day I think developers do understand that you're building a company, you have to charge for certain capabilities that you are, you are providing. So I think that comes down to how you segment your product and your audiences. Pretty intense work if you have a lot of features like this is not easy to do. And I built a pricing team at DigitalOcean and then we did the same at Odd Zero. And that team is extremely critical in making sure we got the right packages for the right ocean.

That is the key. Making sure who your ideal customer is and designing things that fit them. With auth0. How do you look at channel to help drive demand? Are you seeing more revenue through cloud marketplaces or traditional reseller partners or is this just community led growth?

Yeah, the partner motion was fairly new. We started the year that I arrived and we did see good traction from marketplaces. So specifically AWS Marketplace was really good for us. There are other channel partners too that we're now investing into. We're actually maturing the program. So now we're spending time with global sis and in our case we also have regional systems integrators that we have to think about. And so we now have built a formal channel program where you can train them, they have enablement materials. And so we're finally outside of the AWS marketplace. We're also seeing traction now with global si, but. But it takes a little bit of concerted investment and enablement for that to. For that to work.

Yeah, yeah, definitely. The good advice there on Amazon's Marketplace was that I guess you guys were there early on, probably in their early days of launching the marketplace. So that also enabled you to get some traction, right?

Yeah, yeah, I think. Yeah, that did. And we had a good relate. We do have a good relationship with the AWS team by the way. Just a fun fact actually. AWS has a product that competes with our core service called Cognito. And yet we found that there were. Yeah, again Cognito works for many use cases, but we also found that for more complex cases or where those scale requirements. I think AWS really wanted their customers to be successful. They sent business and leads our way because I think they ultimately believe that you got to do right by the customer and they want. Obviously they want the customer to stick in the AWS ecosystem.

Awesome. There's a question here. The right time to go to SaaS. I think it's. It was still all software as a service. It's just you probably had this usage based model in these companies. Talk about that a little bit because I think there's some confusion here.

Yeah, so I think at DigitalOcean, everything at the core of the pricing, all of it was usage based but the packaging was different. So for example, we provided the same dollar per minute or hour of compute. Okay. Similar to AWS, but AWS had so virtual machine or EC2 offerings that you would have to scroll four pages like literally to figure out what's the right machine for you. Two different things there. DigitalOcean. One we had more simpler packaging where we combined storage, compute and networking into one. And they were all nice round numbers. Developer didn't have to pull out a calculator and say, okay, if I have to pay 0.005 cents per hour, per minute or hour of compute, how much is it going to be for me for a month? It was pretty straightforward, $5 a month for this configuration. But as customers grew and we had a lot of large customers there too, obviously they were paying. They were not looking at whether I'm buying a $250 droplet or virtual machine or a $5. They were just looking at how much am I paying per dollar of compute per minute or per hour. And they scaled that. And so in the background we made sure that our plans were scaling linearly. And I think that is really important to make sure that for developer LED products, one of the things you want to make sure is they need to have a nice path towards expanding or the plans if you create like this hard gap. And we had that at odd zero, for example, going from a developer pro to the enterprise plan was like such a big jump. And so we're continually working to make sure that we smooth that out. And so customers have a nice or developers have a nice linear growth. And so, and yeah, and even at odd zero, yes, we package. There is a monthly fixed price that you can pay, but it is pegged to in our case maus. So it was still based on usage there Definitely.

How did you determine exactly how much free was optimal? We know that too little and too much can suffer paid conversion. So what's that right window of free or time trial you found?

Yeah, for free trials we ran a lot of, frankly we did not know. We ran a lot of experiments. So we're in experience with 15 day, 30 day, 45 day, 60 day. We even did three months. We done 90 day free trials. What we found the sweet spot was 60 days was enough for somebody to really understand value. So the way we did it at DigitalOcean was that if you were a hobbyist developer, you would get a 30 day free trial. If you were a business, then you would get a 60 day. And we found that time was pretty, pretty sufficient for you to get value. We did not however limit the products that you could do the trial on. At least in the case of DigitalOcean, if somebody wanted to try database as a service, we wanted them to. We didn't limit what they could or could not trial over at odd zero. I think again there are some features that we limit. For example, how many enterprise connections you have in a certain plan. We limit the products that way. But let's Say if you did go over, we didn't shut off any of our customers, we just send them essentially a message, hey, you're over quota based on what you had signed up for. Now is a good time to upgrade. So we never impact the customer in a negative way and we're able to get them to upgrade. And I think over time what we've learned is you will know which are the right features and what buckets you want to put to segment and you will also be able to explain the value of that decision. And again, just fair warning. I think if you're selling to developers, they're a pretty hard audience to win over and speak to authentically. So I think as long as you show that you're thinking about that, you need to capture that value and why that value is important, I think you're okay then. But you'll have to run a lot of experiments.

Definitely now experiments make make sense. You can't just put something out there and just pray, right? You got to test, you got to validate, you got to iterate, then you scale. Once you've validated your productize and scale, Sachin asked here, what mental models should founders apply when working on the GTM plan and deciding whether it's product led or sales led or community led in the B2B markets?

Yeah, that's a good, that's a good question. So I think it depends on where you can create this community feedback loop, right? So I think again it comes down to what are the hooks going to be. So let's talk about product LED first. I think there it's going to be, do you have enough early insights or signals onto how if there are enough hooks for you to build this, give tremendous value right out of the gate to a customer and then you have an opportunity to upsell or move them through a maturity framework? I think that you have to think through. It also depends on the type of market you're going after for community based. I think, I think in both cases, in case of DigitalOcean and Odd Zero, we found like these underserved audiences. Okay. Like actually a funny tidbit. Like when I would go to conferences, this is how good the content became from DigitalOcean. We even had the AWS Devrel team come walk up to us and man, we really love your content. And we had a lot of customers who were actually building on AWS would come and say, oh yeah, I came and I learned how to learn XYZ technology and cloud on your platform. So I think you have figure out where are the large underserved segments and audiences? That usually is a good early indicator of your community based signal. And oftentimes it's not like these things operate in a silo. There's usually a combination of product led, community led and like I said in the case of Odd zero, we also had sales led motion. So it was like a nice, we stitched those seamlessly. And so I think those are the things I would look for is what is the surface area of your product and then what is the surface area of your audience in terms of how underserved they are and that could drive your community strategy. Like I know right now, if you look at gainsight with Pulse and I know another ex digitalocean colleague who's built in Catalyst, they're doing community building around CSMs. Right? Again, CSMs were underserved and so now you have these two companies going after creating heroes out of customer success managers and building a whole community around that. It's because the were a very large underserved community. So I think those are the signals or that's the framework I would use to decide where to get started.

Kevin Chu from Catalyst is a very good friend of mine and he was, I met him because at Speakeasy he was my first paid customer and we stayed on. And that's our philosophy at Bose too, right? Like our mission is to make innovators become successful. We serve that to our product. But we built the community traction community to give them the resources to become successful. And that's a model, that's. It's a painful model. When I say that meaning you got to really love community building and somebody on the team needs to have this innate desire and DNA to give and not expect anything in return and thrive on relationships. And luckily that's been my superpower. So let's dive into communities and ecosystems here. What is your definition of ecosystem? Is it a community, is it a movement? Is it the same as a marketplace? What does that mean?

My definition of ecosystem is different. It doesn't always imply marketplace and I'll tell you why. Because I think marketplace has an implication that there is some commerce or exchange, right? There is some rev share or there's some transactional value there. But I think ecosystem is bigger than that. You can have a very good thriving ecosystem or developer ecosystem and not have a marketplace. And I think in the early days, especially when you built building a new product, let's say if you're building a new open source initiative or there's a new technology that does data Automation because everybody's doing data these days. So I think there first build the and usually early you will build a community first. Whether it's community of contributors or community of early adopters. You want to essentially get to a certain size and scale. And the developer ecosystem when building an ecosystem doesn't always have to be a transaction, but it can be other value. In the case of like DigitalOcean, the ecosystem was all about open source and content around open source. That was valuable. Right? And so I think of ecosystem as much bigger than marketplace and I at least in the way I think about it mentally marketplace is a, is a component of ecosystem, but you don't always have to have a marketplace. I think you can build an ecosystem without a marketplace. Although I've seen most large developer ecosystems ultimately get into a marketplace. Whether you look at GitHub, DigitalOcean, Trilio, AWS and others, ultimately you do get there. But I think that has to do with size and scale.

It's part of bringing value to the community you build by bringing on other partners to deliver value. Because you can't do everything as a company. What are key components of a successful ecosystem? What are some key traits here?

You probably need some critical mass of users at some point. And if you're building and if you're relying on a community, I think you just need a healthy community, whether that's contributors or community that's exchanging information or knowledge. We've also found if you want to build this and you want to grow it, you have to also think about creating a big portion of onboarding your community partners. Whether it's individual developers or vendors or partners. Whatever name you put on, like a self service platform is really critical if you're going to scale and, and then I think just aligning incentives like some marketplaces are two sided, some can be three sided. And so you want to really make sure that, that your platform is, is open and that the incentives there are aligned. Because if they aren't then you know you're going to miss out on one of the demand or supply side of the, of the equation. And I think the, the last thing I think is, and this is more about marketplaces is that you have to be upfront about what your intention is. I think there is a lot of both individuals and companies who have been burned by being part of a marketplace and then the marketplace they're part of will launch a product or feature that competes with their, with what they have done. And so I think that is a tricky one. You want to be upfront to make sure that, that that you're not going to essentially put see what your partners are doing and put them out of business. That's not a headily held in something to watch out for.

When was. When is the timing right to get into the whole ecosystem game? When did you do it at do@auth0 Some people say you need to be at 100 million before you even think about that. So like when is the right time?

It's funny we did this in both examples we did it after 100 million in ARR but I, but I think that was more by accident and not because we were intentional. I think it's less important whether it's a hundred million ARR. Maybe you want to look at how many customers you have. So in the case of DigitalOcean it was over 500,000 and at odd zero over 26,000 or something like that. And I think the decisions were mostly based on when the platform was ready ready because launching an ecosystem when your foundation isn't ready I think will hurt you. So I think it was more based on do we have a foundation strong enough and robust enough to launch now this sort of ecosystem or marketplace or partner motion. And then I think with ODD zero there was also another thing is that we had done integrations prior to my arrival but they were just really hard to find. Discoverability was an issue. They were all over the place. Maintainability wasn't quite right. And so we focus on building the core and making sure that we were ready to take on partners. Because even if you build a self service motion by the way with partners you still have to think about what is a support model. If there is a transaction, if there is a value exchange, how is that going to happen? What is a support model? How do you end of life, let's say a vendor decided they're going to deprecate something. I think you have to think through a lot of that and and if you're building a developer product or a security product, you also have to think about compliance and security considerations. So I think those are some additional things you have to be ready to take on because otherwise you'll just be a bad experience on both sides.

Definitely. How do you build a great product team? I want to dive into this as we part ways here. We have coming up on the top of the hour.

I'm a big sort of believer in like small team. So even at DigitalOcean we had teams no bigger than six to eight obviously pairing with a product manager or designer and the engineering team and and just. And you have to make sure that you architect your platforms and teams in a way that teams can iterate independently. When you're in a high growth company that is not always the case. Almost every high growth company that I know has monolithic architectures. Certainly we. That's been my experience. And you'll have your fair share of tech debt and product debt that you have to deal with. So I think the important part is just making sure that you set up these autonomous teams where they make sense and where you are not ready. Just hold off and make sure you've re architected because you can easily fool yourself to think I have 14 independent teams. If the platform or architecture doesn't allow it, your 14 independent teams will be fighting and will be in dependency hell anyway. So I think and just making sure you're structuring small teams and invest a lot in aligning these product teams because you want aligned autonomy. A lot of the times you're in a high growth company that's the thing that can go arise is your alignment. And I personally invest a lot of time in in aligning your teams having a clearer vision because then autonomy is so much easier to be had. And a big part of your your job is then recruiting the right people who can take the mission mission forward.

I spoke I hear this theme over and over again. Give them the mission, the vision, the metrics, the values and then give them the autonomy to execute. Be an innovation, input, don't be an approver. But then communication comes becomes a big part of that.

Right.

Like it's your job as a leader to clearly articulate the vision to excite and inspire and entertain people. If you're just saying it to say it then you may as well send a text message and it's boring. But how do you manage internal communication at scale right now?

Yeah, this is constantly work in progress. We we do regular all hands even at our size. Like my organization is quickly coming up to 500 people. So we do still do regular all hands by function and by my entire org. We have a good practice of monthly newsletters. So we have these autonomous teams who are constantly publishing their own blogs internally. And so we try to combine those and highlight kind of like in case you missed it, right. I kind of newsletter and then for. Because we're also. We were remote and we still are remote. We are just very good at doing a lot of asynchronous work and we write a lot. Like I personally write a lot write a lot. Whether it's blogs, strategy Documents just so that we can bring our teams along in an asynchronous fashion. And then so a lot of onbound communications. We all Also occasionally do AMAs where won't be just a readout of our goals or updates or wins. Just like, hey, let's just hear all the challenges and issues teams have. And I'm finding at least for one on ones like audio calls work way, way better because of the amount of, of time we're all on video. And that's something that I've been incorporating at least in my one on one conversations to do to do more audio so that you're really focused on a particular individual and conversation. Because when you're on zoom and on screens it's so easy to get distracted and no matter how disciplined you are, you will get distracted. So that's. Those are some of the things we're doing.

And then from a sort of you're in the world of zoom and virtual and pandemic and still hyper growing. Right. How do you ensure that you achieve hyper growth without burning people out in this environment? Because I'm seeing this all around me.

I'll be honest, this one's just hard. I don't think we have figured this one out. We have not cracked this. So we've tried different tactics. So for example, we instituted no meeting, no internal meeting Fridays. Hard to do no meeting Fridays because you may have to speak to a customer. We also did days off and wellness days. For example, we gave our entire organization the week of Thanksgiving off. We already have an open vacation policy. So trying to enforce that, that. And I also instituted sort of no after hours slack. And so we're using, because we were very slack heavy. And so we're using ways not to interrupt teams in different time zones. We also have invested in coaching tools for managers. We've also invested in online mental health mindfulness tools to help. But I, I gotta be honest, I don't think that we have solved this. So I personally see it and I think the trick here is it has to be top down. Like, because you mentioned of like you don't have clear boundaries so you could be working the whole time and if you're not careful, you can end up just doing. And so we're trying to also reduce the number of priorities or commitments we're making. And maybe that's, maybe that's one way to take the pressure off of teams which is saying it's okay to do less and things we control we should definitely push out rather than create some unnecessary Pressure so that. So this is still work in progress. Haven't figured this one out.

Definitely. Awesome. We're at the top of the hour here. Before we part ways, what are your top two or three pieces of advice you've learned the hard way in your career?

You know, you asked me a few years ago this list would have been different right now. And again, because I'm always learning too. I think right now for me the three things I've been hiring is really important because when you bring the right leaders, it allows you to scale and especially in hyper growth the tendencies I can do it all. And I think that's a mistake. You have to bring in other leaders so that you solve your management bandwidth issues. The other thing that I've learned, at least with these two companies, is when you have this extreme product market fit, it has this gravity, it's a pull pulls you towards the center, which is like the core product. And you can easily get sucked into the vortex of serving your current customers and your current products. And I think it's really important to look for ways to disrupt yourself despite having all this success. And so I think it's critical to, to keep an eye on the future. And at least I've been deploying this model where, you know, you kind of want to work on, on two different horizons as companies grow really big. You might have three. But I think it's healthy to say there is always a team that's thinking about the next 12 to 18 months. And then you want a team that's thinking beyond the 18 month horizon so that you can think about some more disruptive trends or technologies that are coming down the line. And so that's been like a big one for me.

For me also because oftentimes people fall in love with their solution, not the vision or the customer. And that's when you get stuck doing the same thing and bloating it versus focusing on the vision and the customer. Then the solution evolves and you get more and more innovative. I like that horizon. Like you said, 18 months and the immediate and then the beyond 18 months. Because you got to constantly change. The only thing constant is change. How does the audience follow you? What social channels are you active on?

I am mostly active on Twitter, a little bit on LinkedIn, mostly active on Twitter and I think I tried Clubhouse, but I just couldn't keep up. Too many conversations going on. But yeah, Twitter and fairly active there and we'll post a lot of stuff.

What's your Twitter handle?

Think Shiv. Like think Shiv.

Think Shiv Twitter handle and just Shiv Ramji on LinkedIn. It's been a great pleasure, Shiv. Thanks for joining us. I learned a of ton fun. I'm sure the audience learned a ton. Have a wonderful weekend. Coming up, I need some traction.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast.

If you enjoyed the show, please leave.

Us a five star review and you can find more information and all the resources mentioned in today's episode at. Boast AI that's b o a s t AI forward slash slash blog on.

The tech stack thinking it was brilliant. Now I know that it's no way for you to build a.