Guy Podjarny is the Founder of Snyk, a security platform that empowers software-driven businesses to develop fast and stay secure. Prior to Snyk, Guy founded Blaze which was acquired by Akamai and became CTO. We talked through the topic of acquisition — the sale, the merge, the learnings, and why Guy might not be planning for Snyk to be acquired anytime soon. We started the conversation with Snyk’s recent raise of $150 million dollars.
Guy Podjarny: I’m actually quite passionate about the freemium vs. free trial type model… So what I feel is that people conflate them. Snyk is a freemium model. And what does that mean? I’ll extrapolate beyond Snyk for us… Which is we actually serve a use case for users that would never pay us. And we serve that use case really well for a long period of time… Again, until they basically don’t qualify for that use case.
For us, for instance, we support individual developers who want to secure their applications, as well as small teams, within our freemium tier. And there’s no buts, there’s no exceptions. We also support open source users. That’s maybe even the first profile, or people protecting open source platforms… And those users should be - we do all we can - to make them really happy with the product, independent of whatever purchasing ability. There’s a use case there about an individual developer, about an open source developer, about a small team, where the product should within the free tier truly deliver success. And in general, I think in freemium that’s what you need. You need to define a use case that you will support for an extended period of time, or forever, presumably, that people would run.
[44:00] Free trial is really about a chance to explore the capabilities of your product. And what people do is they call it freemium because they think of free trial as something that is only limited by time. So they say “Well, no, if it’s not a time-limited thing, it’s not a trial.” But in practice, they don’t solve any use case… So they for instance – say you have a collaboration tool, and you allow collaboration for up to five users as something that’s within your free tier. But your product really only brings true value - you know, the product that you’ve designed is really around large group collaboration. And collaboration amidst five people – let’s assume for a second it was like a Slack style system… Well, the value is fairly dubious. It’s not really that significant. When you’re five people, you don’t really care about that much assisted collaboration between the five of you. I mean, you can communicate pretty well.
So you find yourself not really solving a problem, and in earnest, you don’t actually want people that are five-person teams to use it. What you want is you want the 100-person team or the 1,000-person team to start with five people. But for those people, you never started, you never solved an actual use case, an actual problem that they’ve had. And so this type of mistake typically happens when people think about freemium last. What they basically do is they say “Well, I’ll build a –” let’s say in our case I will build a security solution, I will price it by the number of developers building the application, and therefore now how do I keep people? I’ll give people something for free, but I will keep it from encroaching on my commercial; I want to keep enough value in my premium tier, so that there’s enough people that would move over to upgrade.
And so they start from that, and they reduce it back down. Or they now say “Okay, I will only allow up to five developers.” If I was to do that, and I would say “Well, it’s only teams of up to five developers”, then basically none of those is probably going to be that significant kind of a customer. If it’s organizations with no more than five developers, that’s not really the profile that I’m trying to reach.
So what you really want to do is you want to understand for a given user what is the use case that you are solving for them. You start with the users you want to reach, the people that you want to reach in the first place. Developers as a whole, and then developers within enterprises. Then you wanna say “Well, what’s the problem that you want to solve for them?” Let’s say you have a team over there, or you have an individual developer there - what is the problem that they want to solve? Well, they want to find out if there are vulnerabilities in their code. And now you build a solution that helps them address that, helps them find those problems and be very comfortable with the fact that they will never pay you.
And then as you expand it, when you think about like “Okay, another use case for us is developers in open source”, like an open source project developer. Well, what is the use case that I solve for that user? I help them integrate into their open source project an ability to identify and fix known vulnerabilities… And I want to do that indefinitely. What I want those two developers to do is very different. The developer in the enterprise - what I want to do is I want to make them successful, but then I want them to help introduce to other team members, I want to inform them about my commercial capabilities, I want them to engage sales when appropriate, so that they would go off to the purchase.
The open source developers - what do I want them to do? Well, above and beyond, again, like the first case, being successful and loving the solution, what I want them to do is tell the world. I want them to help the world know that open source security matters, and that Snyk is a good way to address this… So if they publicly talk about me or about Snyk, and if they help educate their peers, then that provides that value… And I shouldn’t bother them around purchasing. I can also consider saying “Well, if I think that this person might work at a job, work on also non-open source projects, maybe I want to have them consider using Snyk in that surrounding.”
[48:34] So these are all very Snyk-specific examples, but I think that the key distinction here is when you have a solution and you think about how do you bring it to market, there’s this aspiration that it’ll be a freemium-led go-to-market; so you want to get these masses of people using your product, and you want some portion of them naturally growing to buy your product. And what often happens is you will unleash a freemium product and then nobody would use it, or the products would not really get adopted. To avoid that problem, or if you see that that’s happening, you have to stop and think “Who are the people that this freemium product works for? What are the use cases that I’m truly solving for them, and what is it that I want them – that I as a business (a little bit more cynically) want to get out of them?”
And you know what - if you can’t figure those out, that’s entirely legit. You don’t have to have a freemium model. If you don’t have those solutions, if the minimum use of your product is one that really should be commercial, then it should be a free trial. But then you should adjust your methodologies, adjust your expectations that what you’re really doing is you’re offering them a free trial, and you should convey it accordingly to them, to say “This is a trial of our capabilities”, so they don’t have the misconception that your product is limited in the way that you’ve provided it.