Forgepoint Field Guide | Product-Led Growth: Getting to WOW and Scaling It
Connie Qian
November 16, 2021
- Blog Post
For this edition of the Forgepoint Field Guide, we caught up with Jon Gelsey, currently a board member for Symmetry Systems, Inc. and Macrometa Corp. Jon is the former CEO of Auth0, an iDaaS startup acquired by Okta for $6.5B in 2021, and the former CEO of Xnor.ai, a deep neural network ML startup acquired by Apple for $200M in 2020. During Jon’s tenure with Auth0, which he took from Seed to Series C, the company grew from 3 to 300 employees across 35 countries and acquired customers in 100+ countries..
Jon, thank you for joining us today for our Field Guide for founders leading early-stage startups.
You helped Auth0 during the most critical stages of a startup’s formation by applying a robust product-led growth strategy. How did you do it and what is “Time to Wow”?
Product-led growth allows you to scale lead generation much more quickly and less expensively than traditional marketing approaches. There is a myth that PLG means you don’t need an enterprise salesforce, but that’s not accurate. Instead, PLG when done right is an inexpensive way to generate high-quality leads for the top of the sales funnel.
The two most powerful marketing techniques are the “free sample” and the “recommendation by a trusted friend.” PLG automates these techniques to a great degree to initially generate leads, then allows for automated qualification of a lead through behavioral signals — so that a human salesperson gets involved at the time the lead is demonstrating a reasonable likelihood to buy.
Content marketing (done right) is the key to a successful PLG strategy because quality organic content generates great SEO for likely queries about your product. Great SEO is probably the single most important PLG metric; it means your content is useful and authentic, and that web sentiment is positive. Great SEO “automates” the “recommendation by a trusted friend” pillar of PLG, so that Google becomes the trusted friend in your prospect’s early discovery and evaluation.
Another super important aspect to implement — in addition to your content marketing strategy, as well as a critical pillar on its own — is the “free sample” with a short “time to WOW” when first tried out. Think of it this way: Google SEO generates the motivation to check out your product because trustworthy sources are saying nice things about it, so you must allow the prospect to be impressed by the product quickly, which means without the friction and loss generated by a “Contact Sales” button.
“Time to WOW” means how quickly your users experience a rush when they sign up and try your product for the first time, and achieve something in a few minutes that typically might take hours. The goal is for users to think to themselves, “last time I tried to do something of this complexity it took hours or days to get it running, not 10 minutes!”
Examples we looked at when we started Auth0 were our first experiences with Stripe or Twilio. Their quickstarts let you send an SMS or process a credit card payment in 5–10 minutes of configuration and coding. There’s nothing like a short “time to WOW” to convince a sophisticated, cynical buyer it’s worth spending more time to further evaluate your tool.
How did you translate developer traction into an Enterprise Sale?
Well, that’s maybe not quite a holistic way to think about it. When you are selling a piece of enterprise infrastructure, the actual users like developers, or DevSecOps engineers, or SREs are one side of a super powerful economic motion called a two-sided market. It’s comparable to how credit cards are a two-sided market, because you decide which card to use at a merchant, but that merchant pays the MDF fee to the bank.
If PLG is done right, the actual users — the developers or SREs — are the decision-makers, and the CFO or VP of Engineering pays. This is an awesome phenomena when you see it in action, and it allows you to sidestep the bottleneck of you having to convince the senior executive to buy — because the developers who want to use your product convince the buyer instead.
BTW, it’s important to offer the entire product for low usage as part of the “free sample”, so the evaluator can actually see how powerful the full feature set is. At Auth0, we had the philosophy of “we don’t make money until you make money” so offering the full feature set for low usage (or some other proxy signal for non-production use) worked awesomely for us, and made the transition from free to paid, like non-production to production use, to happen sort of automatically.
How did you think about growth and prioritization across the business (e.g. product, people, traction/revenue, and when to fundraise)?
If you have the ability to be more predictive, that’s great, but usually it’s when you’re feeling pain that you do something about it, and that’s a fine heuristic to use. When your salespeople are too busy and aren’t following up on leads, it’s time to scale sales. If your sales team isn’t getting enough leads, it’s time to scale marketing. If your planned feature list is getting too long, it’s time to scale engineering. Hopefully you’ll see the trend that tells you to start scaling before the pain gets too bad, but a little growing pain is better than overprovisioning a team and then having to cut headcount 6 months later.
There are a few areas where this does not really apply, like a CEO should never ever shortchange on security. When you get hacked, and everyone will be these days, you’ll want to have minimized the blast radius and to be able to publicly explain in detail how you had followed best security practices to try to prevent the attack in the first place. If you fumble security, and set yourself up to fumble the PR response when you eventually are hacked by not having best practices security, it can be an existential risk for your company.
Another item not to shortchange is marketing experiments: you have to continually experiment with marketing tactics because you don’t know what will work for you, or whether something you tried before might work or not work now because you’re a different company than you were 6 or 12 months ago. And if you don’t experiment to scale your lead generation, it will generate future pain that will take a while to recover from. So do as many low-cost tests as you can in the form of actual scientific-method experiments — a falsifiable hypothesis and solid data gathering methodology — to guide you on where to invest more.
How did you set the pricing strategy and evolve your terms over time?
Pricing is the hardest thing I’ve ever done and I’m confident I was always wrong. All you can do is experiment, especially if the market has not already set a price. Don’t think that just because, say, AWS prices a certain way, you have to. We charged primarily for usage at Auth0 - first order scaling was on usage, then second and third order was on feature upsell. If you are not selling a commodity, comparables are not necessarily the best way to do pricing, because you are selling something different and hopefully more valuable than the other company that describes their product the same way as you do.
Tell us about your support infrastructure and extensibility. Auth0’s CSM team was empowered to build custom features for large enterprise customers?
A massive, massive secret weapon of Auth0 was “Auth0 Rules”, which allowed our salesforce to never have to say “no” to a feature request from a customer. A “Rule” is a snippet of code that runs in a secure, isolated serverless environment to customize the authentication transaction and/or retrieve additional metadata to enhance the user object. We made it a point of letting JavaScript be our DSL for these snippets, since everyone knows it and there are a wide array of developer tools available for it.
(An ex-Auth0 VP Engineering, Tomek Janszuk, invented this Rules architecture, and has actually started a company Fusebit.io to offer extensibility as a service!)
The cool thing about having extensibility built-in is that it allows new features and functionality to be created without any changes to core code. Since every enterprise has a different and often messy identity environment, extensibility was the path for allowing our customer success engineers to write a new feature, or for the customer to do it themselves.
This allowed us to win deals more quickly, to scale faster, and to let the customer success engineers have fun. It also turned out that extensibility was also awesome for product management, since popular rules would be strong signals for what new features to add to the core product.
How did you take a dev-focused solution to VCs who often look for more traditional SaaS monetization models and metrics?
We actually never aggressively took Auth0 to VCs, because our PLG way of marketing generated the web buzz necessary to entice them to come to us. And then of course when they came in the door, we simply led the conversation with our awesome PLG-driven financial statistics, which usually pretty quickly generated a funding offer.
Of the learnings from Auth0 that you brought to Xnor, what didn’t work?
I found that PLG works best for a commodity offering, not a bespoke offering. When we started Auth0, there were 20 companies offering auth, or you could write it yourself. Everyone understood what it was, they just hated implementing it. Since they understood auth well, evaluating Auth0 through our content marketing and free sample was a task most engineers knew how to do well.
Conversely, with Xnor, we were selling ML models that give you a probability score that the pattern you’re looking for is there or not. Most people then— and probably most engineers now still — don’t know how to build a good ML model, or how to evaluate them. Since evaluating ML is still a difficult art, evaluating Xnor’s offerings versus others was harder for ordinary engineers to do.
How do you compare and contrast scaling DevOps vs. Cybersecurity (or DevSecOps) startups using PLG?
PLG tends to be more effective when selling to someone who has been granted unilateral decision-making authority for an implementation because the downside risk to suboptimal decisions is low. “Bob the developer will pick the auth component, but if it turns out he picked a bad one, its problems will show up in testing or after we’re in beta, and then we’ll just rip it out and replace it with a better one.”
But an offering that has implications enterprise-wide and therefore high downside cost tends to have a committee deciding on it, because for example, a bad security decision can create an existential risk to the company. Cybersecurity tends to be a sale to the security team to help them implement a high risk/high reward security strategy, so tends to require a more traditional relationship selling motion.
Similarly, the acquisition of your offering by a DevSecOps team could also be viewed as high risk and hence harder to promote via PLG, as perhaps the wrong offering could take the entire enterprise offline.
Jon, you advise multiple startups. What’s one piece of wisdom you’d like to share with fellow or future entrepreneurs?
Don’t be afraid of taking on the CEO role because of imposter syndrome. It’s an experiment where you test yourself to see how far you can stretch. You’re unlikely to be any worse than someone else and may even be tremendously better.
Also, life is uncertain, so carpe diem. Enjoy the day!
This article is part of the Forgepoint Field Guide, an interview series focused on early-stage company building.