a16z Podcast - a16z Podcast: Pricing Free

Episode Date: August 19, 2016

Now that we know to price and plan early, price high -- especially for category-creating or "pre-chasm" businesses -- how do we handle freemium models? While free to premium is a great way to get bottoms-up, often viral traction in an enterprise, the challenge is figuring out just where and how to "draw the line" between where free ends and paid begins. Especially for open source, which while not necessarily free/mium, is also affected by these questions. And in that case, how does one balance the developer community and desire to "spread the religion" within and beyond the enterprise? All this and more in this episode of the a16z Podcast with Andreessen Horowitz general partners (who cover all things infrastructure) Martin Casado and Peter Levine and Go-to-Market and EBC operating head Mark Cranney. The trick, they tells us, involves layering ... like layers in a cake.

Hi, everyone. Welcome to the A6 and Z podcast. I'm Sonal and we are continuing our series on pricing. We've already talked about why to raise prices, how to go about doing this. And now we're talking more specifically about pricing freemium to premium as well as open source and what that means. Joining us to have that conversation, we have general partners Peter Levine and Martine Casado, who cover all things infrastructure. And we have Mark Cranny, who heads up our go-to-market practice as well as our executive. briefing center. Welcome, guys. Thank you. All right. Peter, you want to kick it off. So as we think about freemium to premium, you could either give something away for free, give some value away for free. The idea of freemium is that people get to self-try and you give away something. It doesn't have to be open source does not mean freemium. You could have a closed-source product that has a freemium component to a premium component, but open source tends to lend itself towards kind of wide adoption with users using some sort of free adoption,

viral kind of penetration through an organization. The way I think about Freemium is that it's a proxy for marketing spend. You tend to have to spend quite a bit on marketing in order to get the user to see the value of a given product. What Freemium does is it offsets the marketing cost. You have to give away some features in your product. but through adoption inside the enterprise, he actually can get some nice traction

and users using your product through a freemium model and not spend a lot on marketing because in a sense, the user is the sales organization and the user is the marketing organization in a premium. Now, the whole notion of premium is that users, individual users, while they can certainly get benefit and appreciate certain features in a product, they often can't see all features that may be required in an enterprise. An individual who's

doing job X may appreciate a certain feature, but there's maybe 10 other features in the product that they wouldn't necessarily use or appreciate, and that may be a different group who would say, yeah, those features are great in a different sense. So the idea of a premium, having premium on top of a freemium is to start generating revenue on top of the underlying base. And with that, I believe that you need to have a sales organization actually come in to sell the premium products such that the users can be educated, the organization can be educated on the additional features that are available outside the base premium products. So all of this pricing really sort of starts with a proper go-to-market model and a thought,

thoughtful articulation of what the features are in the base, what the features are in the premium, and how you sort of shape that and take it to market. How do you take the reins on that, though? And is it really that thoughtful up front? Because bluntly, when you think about the narrative of how a lot of startups and their products take off, there seems to be this viral phenomenon that happens where it's being adopted bottoms up inside the company. And there's no salesperson involved.

That's a starting point. I've heard both of you say, like, then you need to have, you still need a sales force. So but do you really? It's sort of a head. when, you know, the best products, the products with this unbelievably great product market fit from day zero with freemium start to take off. And the assumption is like, oh, well, look at here. We don't need a sales organization. Let's just go hire more engineers. And the market will just continue to uptake. But what we see is over time, that curve starts to flatten out because the number of

users and kind of the virality starts to slow up and the value that one can get out of the revenue value that one gets out of that from an organizational standpoint can never be realized in the same way as when you have a sales organization actually selling and educating the organization on the benefits of this from a selling standpoint the key a couple keys one where is that functionality line or where is that drawn for the individual user that's using the free functionality. I think in a lot of cases, we see companies wait too long to start thinking about and drawing that line so they can get to a premium type offering.

And then two, as you move up the stack in an organization, particularly the bigger companies in enterprises, a lot of the functionality is going to be drawn around the lines of how does that product enable companies to work across multiple work groups? And then as you move up another level is what is that going to mean to the business overall? From a go to market standpoint, I understand, all right, I need to dig into those three buckets. You know, what is the criteria, the buying criteria of those individual users? What's going to thrill them? What do they need to do their individual jobs and then take another step back, look at that middle layer of the work groups, what kind of layers of functionality is going to be important, you know,

maybe from a collaboration standpoint or a workflow standpoint. And then, yeah, and then as we keep moving up, you've got things like security, enterprise hardening, working across multiple geographies, how is it going to scale? You know, it's more architecture things. As you get in the second and third buckets, you know, there's a lot of the second and third buckets, you know, there's a different type of sales force that may support that. It might be inbound, right? You know, people on the phone. It might be more technical oriented. You need to think about layering your sales and marketing and go to market efforts across all these three different buckets. Can I just insert a quick note of caution here? I think this is a sufficiently complicated issue that just saying,

you know, you add a sales force may not highlight some of the potential pitfalls. So one thing that we've seen a lot of is, you know, in order to get kind of viral organic adoption, it's good to have a low price. Or no price. Or no. And honestly, if you are entering with a low price to get viral adoption and you're trying to do something that's bottoms up, often you start setting the price in the market. And that's very, very dangerous. The number of companies said, okay, instead of building a sales force, we're going to try to do bottoms up. They set pricing very low per developer pricing.

They matured the market that way. They got some adoption. And then because they weren't, you know, the customers were educated on the features, somebody wasn't showing the value, you know, it started to tail off. And then now they're building out of Salesforce, but the sales force is hampered because they actually have fairly mature pricing in the market. And so I think going into this knowing that there's going to be this two-pronged approach, like knowing beforehand, planning beforehand, so you don't mistakenly set the value too

low in the market is pretty important. Yeah. Companies that go take that approach, they end up becoming fairly dominant on the bottom end. but you may have another competitor that comes in with sales and marketing, maybe even an inferior product as far as what's attractive to the actual user, but they have those next two layers of functionality, and they're approaching things more from a top-down standpoint, and then you're in more of a strategic battle.

So you could, in some cases, actually get pinned down strategically by, because the best product doesn't always win. That's a very powerful and almost blasphemous statement when you think about tech. I'll take the heat, yeah. You know, in my experience over multiple products, 80% of the dollars comes from direct sales, independent of like how viral the organic is. I mean, it just turns out direct sales produces a lot of durable revenue and renewable revenue. Well, just to be clear, though, when you're talking about premium premium, in general,

or freemium sort of subsidizes the premium by default. So the revenue will predominantly come from the premium sales. Yeah, yeah, absolutely. I'm saying premium is free then by definition. The premium is going to account for the majority of the sales. But your point is that... You're making a further point out the sales organization. I think that there's this belief that if you price low enough,

you will make up for it through penetration. And it turns out that that's not what the distribution normally looks like. Even if you skew it for low price and higher price, the majority of the revenue comes from direct enterprise sales. And so that will be the bulk of the revenue over time. I want to go back to a point both you touched on. delineating the line of features between fremium and premium is critical. For sure.

And premium, it has to have enough value to where people use it. So here's the sort of conundrum and dilemma of this whole thing. It's got to have enough value, otherwise people don't use it, yet you have to have enough held back such that you can actually have something in your premium, right? And so that line becomes a very, very important ingredient in getting this all to work. offer too much. There's nothing to sell on the add-on. Offer too little. And users are like, I don't need this. It doesn't do anything for me. And that's a very slippery slope. The whole support model really not being very viable outside of what Red Hat has done. And we've talked about this

for years. But I would say that getting that feature set exactly right up front is really, really important. Like don't back into it. Don't say, well, we're going to give every away for this year and then we're going to strip things down because like once you give things away you can't just take it back and you know if you give too little you may not get the traction so it's really important to get that balance as perfect as possible it's a process not an event it's something you're going to be constantly cranking on knobs and understanding because and it's got to be tightly integrated with your vision and product roadmap a lot of that stuff is it's going to change over time and that balance between, you know, the community, if it's open source and or the user's taking too much away, can slow you down.

Having been the CEO of an open source company, community is one of the most challenging open source forces that you will face as a company. And that is, how much do you give away for free versus how much of the product do you withhold for revenue and the pressure of the community to make sure that that, line is properly adhered to. Right. You can't isolate them. The community may say, well, look, we want all of this stuff for free. And as the organization trying to derive revenue, I mean, after all, open source companies are for profit. They're not charities. And so you need to figure out a way to go make money. And that's often in conflict with the community. And they're a lot like religions. Exactly. The open source community is very religious about that. So here's the issue that a company faces. If you don't manage the community in a proper way, the community will say, well,

they're not doing what we want. We're going to fork the code and go run off and do. We're going to just do the whole thing. There's always that tension between unlimited, free open source and all the features versus kind of constraining things around a freemium premium. I'll start my own churches. Exactly like religion. That's how they all started. So what do you do then? You guys have talked about this multiple times on the podcast. for listeners. You can listen to our podcast on open source and developers. What do you do then? Do you just not build a business like that in the first place or do you find a different solution? On the last pricing podcast, I think Mark had the right advice, which is if you're going to be doing

tiering based on features, you've got to understand this really early on and it has to be part of the product development cycle. You've got to make it actually part of the iterative cycle. Like you have to think about it every time you do it. Even if you are still just building the freaking product and just working to keep the freaking servers running. Day one, building the product means having a thoughtful tiering structure in how this thing unfold from day zero. Let's say you want the product. Let's say there are hidden features in the product that you want to unlock via some automated fashion, just as an example. Well, you got to plan that in. It can't be an afterthought. The freemium product can actually help to sell itself if you

think about the interface thoughtfully and some of the other bits and pieces. But that's as important as the functionality of the product should include the pricing and tiering model as part of that whole exercise. Yeah, one of those little, I mean, those bits and pieces and knobs of functionality that are going to be the triggers for that product to where you should be charging more than what that individual has either started using on their own or been able to swipe a credit card because it's so valuable to them that they paid for by themselves. and then what are those next two or three levels up and functional?

One could imagine that a product actually helps to educate the customer on the benefits through the interface itself, right? And if you think about that as part of the design criteria, you get better adoption, you get better appreciation for those elements. And just bolting it on as an afterthought is often a disaster. Because it doesn't fit in, it doesn't look right, and all these, you know, kind of, it's been, it's features that you add up, you know, educational features that you add later that are not really baked into the DNA of the product.

I also think going back to the question of like, so how do you decide what to open source and not open source? Here's my experience. It looks like the version you charge for, especially in relation to open source, the version you charge for is kind of a thin layer that you need in order to make the open source functional, I think the community will decry that you're creating crippleware. And so open source needs to be independently complete and functional. Like useful for a purpose, totally independently. Maybe not all purposes.

But if you just put it out there and it doesn't really work or it doesn't really work for something to get a job done, I think that you're going to cause issues of the community or maybe not develop the community to begin with. You wouldn't even get a community. The open source community has matured over the years. And I do believe that the community is sensitive and is appreciative of companies needing to actually make revenue and kind of have a business as opposed to just being a charity where everything's given away for free. There are discrete sort of components of open source that one could argue here's all the functionality needed for a given user, a given server, a given environment.

And then the added value components may be along areas such as scalability, security, enterprise kind of completeness, and that tends to work very well. Because a lot of those added on features are not really part of the open source code anyway. You could argue it could be, but those are more generalized capabilities for enterprise adoption. There are also, in some cases, things that AN Enterprise can go configure and or customize to their specific. use cases and may want to keep inside their organization. So, Cranny, I have a question then because we're describing that the product has inherent value and ideally even inherent education to help it take off and sort of go up from bottoms up. Do you then counsel founders to have the enterprise sales force in at the very beginning,

or do they wait until the viral adoption happens and they get it at a certain point? Like, when is the ideal time to bring in that enterprise sales force if you don't want a competitor to take the top half away from you in the market and the enterprise? Yeah, it doesn't have to be right at the beginning. A lot of it, you know, depends on the traction that they're getting initially. A lot of it's, you know, based on the skill set, I think, of that founding team and, you know, their knowledge of, you know, major buyers or enterprises are going through to get that deep understanding. In some cases, you may need somebody in fairly early to really unpack what that functionality might look like over and above, you know, what, you know, the founder's knowledge is from, you know, say if it's a DevOps type tool

from a pure dev perspective, you know, what's that going to look like in these different types of enterprises from a workflow standpoint? A lot of it depends on what kind of momentum they have, what needs to happen to understand where they can, you know, start drawing that line and putting the pricing and packaging together. So, I mean, it is so case specific. What typically happens is they wait too long, in my opinion, to start putting that in, and or there's a misfit from a higher standpoint as far as the skill set required to go put that in place. Well, this reinforces something we've talked about on the previous podcast, which is this notion of sales, a sales force definitionally as a collaborator and helping discover

buyer needs. But one question I have then, earlier, Peter, you alluded to the fact that in some ways when you do the premium to premium, it's a proxy for marketing. So what then happens now to the marketing? I mean, are you essentially saying that you don't need marketing? Do you agree with that? Yeah, I'd like to pull on that thread. You are, I mean, you might be given something away for free, but is it really for free? I mean, that's something that you might have spent a lot of money from a marketing and sales standpoint to get that kind of usage and adoption and closed loop process feedback. And we see a lot of situations where the, you know, as they, People put the line in on the functionality, and there's nothing behind it from a marketing standpoint, maybe for that next level, the company stall or get stuck.

So why does a marketing matter, though? If the product has value. The marketing might matter for the community to educate them on why it's important to have this next layer or two layers of functionality for those different audiences. So the users will welcome the support of the selling. organization to go expand that usage. And, you know, using the religious term to proselyize and the product, right? You know, they're great missionaries, but they might need some help inside their own organization, you know, to get that type of adoption. And maybe just to clarify my point here on trading off marketing for freemium, that's at the starting point where you have this viral adoption. But as you go to different tiers, in the same way you need to build out a sales organization to

educate on value, marketing also helps to educate that value as well. So it doesn't obviate the need for marketing. I was just making the observation that a freemium model is an offset to marketing spend. You either choose to give away features for free or you choose to spend it in marketing, but in one way or another, there's a cost they're associated with fremium that people often don't think about. I think of layers in a cake. You need to go build layers around product and functionality and how that fits from a buying criteria standpoint, whether it's bottoms up, top down, or layering and all that in at the same time. I think it's worth calling out that, like, there's still a lot.

Like, if you have a sales organization, you're going to need marketing anyways to do sales enablement, for example, right? To do education. A lot of times you do training on customers and certification still really important. Analyst relations still really important to enable a sales force to sell into an IT organization, channel enablement. So marketing isn't just about getting people to know about your product or getting the customers to understand the value. It's way more. I mean, like, marketing is normally very tightly aligned with sales anyways. I think that what you can say is like initial outreach, initial branding, initial touch point, top of the funnel, like that can be aided with freemian and open source, but all of the sables enablement, all of the partner enablement and the customer certification and the analyst relationships, certainly this is something that the marketing function has to do. By the way, is that true for selling to developers too? I would almost imagine they'd be a lot. allergic to being educated or certified. Certainly, like, developers are a lot, an important part of top of the funnel, like getting

their buy-in, getting their support, and sometimes they do have budget as well. But often, you still need to engage with the organization. So I think that getting the eyeballs of the developer, getting used from the developer, you don't need to have this kind of deep sales enablement, clearly, to get them to use it. But once the developers are using it and there are large purchasing decisions from the organization, that's when you do want to engage a more traditional. sales cycle. So if I'm selling to a developer, if I'm appealing to a developer with my product, maybe my marketing spend goes into community development, right? Where it's about having,

you know, get-togethers in a variety of cities. You know, we all work together and we do code reviews or whatever. Well, guess what? That costs something. And guess what? It comes out of a marketing budget. Marketing has a lot of different nuances. You can call it whatever you want. But these things take on different faces based on the buyer and based on the end user. And to the extent that you get that right and you kind of figure out, again, to Mark's point here, who the buyer is at these different layers of the cake, there's different marketing objectives in each of those layers. So, Peter, going back to something you said earlier where you mentioned that freemium and open source are not the same thing, but they're often conflated for various reasons. Can you sort of break that down for us a little further?

premium and open source are two separate things. He can always have freemium. You can always have open source. They can have closed source freemium. But then the packaging model for open source is you can do on-prem, open source adoption with an upsell, or many companies are starting to think about delivering open source as a service. Or a combination. And just to clarify, when you say open source as a service, you mean as distinct from open core model. Yes. This is where open source. is that it's actually provided as a SaaS offering. So I run some open source project or some set of open source projects. I stand it up in the cloud. I put a wrapper around it or not.

And I offer it to an end customer. Whether free or not free is not the point. It's offered as a service. When open source is offered as a service, the pricing is based on the service that you actually provide, and it makes for a very nice way to work around some of the nuances of open source and the whole, what's your support model and all these other bits and pieces. The value is in the service. The value is in the service. Right. Exactly. And it's an up, and there's, you know, upsell. You can always upsell and all these other things. One of them

might be actual the reverse that, you know, it gets traction in the user community, but because of you know, security or whatever issues and or functionality, it's need and or integration requirements that that tape same software may need to be, you know, it may need to be, you know, sold and packaged on-prem. Right, right. Just a whole different complexity of pricing and packaging that you may need to consider. We've seen many companies. You start with a cloud, I'll say a cloud SaaS offering based on open source, viral adoption, great uptake. And then enterprises say, well, like, we need to have that inside our firewall. We want a copy of that. So then the expansion, the sales model actually, in that case, is taking from SaaS to go on-prem

into the enterprise as opposed to upselling necessarily the SaaS model, maybe a different version. And if you just really think about that top layer from a CXO standpoint, you know, they're thinking of, all right, that whole on-prem private cloud versus hybrid versus public. And if you can start answering those questions, there's a different type of value that, you know, these companies can be providing and different types of functionality that can avoid things like, you know, avoid the fear from maybe the executive of being locked into one public cloud provider and or, you know, or I'm locked into just what I'm doing internally from a private cloud standpoint and or on-prem standpoint. So those are the types of, you know, more strategic product discussions a company can be having internally as well as customer facing, you know, understanding of what's going on in the minds and the businesses of these big enterprises. There's a certain humility to it because if you have a religious view, like, you know, I'm never going to serve a hybrid. I'm never going to do hybrid. I'm never going to do, you know, it's pure cloud or nothing.

You kind of realize, like, well, people, what are people willing to buy for where they're psychologically already at? Sometimes the religion goes out the door when the money starts. Right, exactly. I also think sometimes it's on-prem, off-prem is like maybe not the right focus. I mean, I think customers want to now consume things as a service. And whether that's on-prem or off-prem is less important than whether the operating model is managed or not. Yeah. Why even make it about that religious debate?

Like, just talk about what is. Back into reality, right, outside of the geography we're sitting in right now. It is a big issue, particularly when you're talking about regulatory. regulated type environments and that they're just, at this time, there's just not the option based on what they're doing. You know, maybe it's Finserve or healthcare or government. No, that I totally agree. I'm just saying, like, from a product development perspective, there doesn't have to be

two products. Oh, totally. I mean, a lot of the argument for doing a SaaS as opposed to shipping softers, when you shift software, you've got to deal with all the on-prem stuff of, like, heterogeneous environments and maybe not skilled administrators or everything else. Another thing you can do from a product development standpoint, say, listen, actually, this is the same bits. We're just going to, if we do it on-prem, we're just going to go ahead and manage it. So, we don't have to deal with all of this complexity.

So a lot of times, like, this on-prem, off-prem meant two different products, two different service offerings, two different shipping bits, two different engineering organizations. And I actually don't think that's the case. Well, I think that the evolution of enterprise software, which may be a whole other topic, is much more to this SaaS packaging. And it's on-prem SaaS or off-prem. And it's the same thing. And there are a lot of benefits from a ease of use standpoint and simplification. And you skirt all the regulatory issues and everything else. I think if you look at the major cloud providers, you're going to see that evolution happen

where they're going to be a big part of that equation. For what's important for the listeners is like the traditional model is like there's like two different types of software you build for this. And it looks like the convergence now is there's one type of software. Right. And the customers are okay having a management. managed platform that's actually managed by the providing entities so that you don't have to deal with all the complexity of that.

There are different places on that journey, I can assure you as far as are, I agree a wholeheartedly with you from a product development standpoint, but where each, the customers are at all different places in that journey. For sure. A lot of them are struggling with it. Yeah, I mean, when we were working with the government, I mean, we had a model that we just needed to connect to the internet. Like, that's it. I said, all that's all we need internet connectivity. Like, we download software. You can run it.

on any hardware you want. We just needed internet connectivity. And the environments that they were running didn't have any because these are these kind of like isolated networks. So absolutely there's a, there's a gradient. But I would say that you don't necessarily have to make a choice. Like if I look at some of the companies that offer both an on-prem and a service offering, the revenue split is 50-50. So these are significant businesses on both sides. And that doesn't necessitate having to build two products to do that. I mean, I think that if I were to do it today, I would build one product that can be on-prem or off-prem, and it'd be as much as possible the same product,

which is going to require some gives on the on-prem side. If it doesn't require two different products, does it still require two different type of sales organizations and marketing organizations? Because one of the things that we've constantly talk about is that selling on-prem versus SaaS is very different. That's a good question. I think it's case-specific, but in general, probably.

That SaaS model makes it easier for you. users to get involved without a lot of friction and to have that bottoms up and that might require a different type of sales and marketing support model versus the on-prem because typically when you are doing things internally in these big companies, there's hardcore reasons that are specific to their business. And that is, you know, in most cases, going to require a higher in, higher cost sales and marketing model. Because, you know, from a development supports standpoint, you're having to develop hardened requirements and or in some cases configure, customize, or integrate into things, or be forced to have, you know, APIs and integrations into

these environments that might have legacy issues that scale back, you know, decades in some cases. So, and that's all that, that's the cost of doing business to really help these companies get to the next gen from a platform or a functionality or a benefit standpoint. And, you know, the pricing should reflect that. So what, what, One of the themes that I've heard throughout, and we've talked about this across multiple podcasts on this podcast, is that we want to keep prices high and you want to figure things out as early as possible, even if you haven't fully built it out yet to go through this sort mental model exercise of going through that and modeling that. But as a startup founder,

your business by definition is often very unpredictable, where you don't know where the product is going to go, especially if you're still working out product market fit. So what do you kind of counsel founders who are saying, yes, but what if we pivot? Like what happens? then? Like, what happens if the product changes? So, I mean, I actually think on pivots, the problem is easier because you're selling a different product. I mean, it depends on the nature of the pivot. And of course, these are all going to be case specific. I think the failure modes are if you're very aggressive about reaching as many people as possible or as many customers as possible. And as a result, you set your pricing

too low. I think that's hard to recover from. Ideally, you're not pivoting. You're just changing direction, right? If you're, you get a little more agility. And I think some of that comes with, in a lot of cases, it's the thing that got you to the point where you have to pivot is maybe going too far down a path that, you know, just didn't work out because there might have been some hardheadedness. Sometimes that stubbornness might be great to push through that, but, you know, sometimes religion leads you to that point where you could have adjusted earlier. Yeah. And maybe a takeaway for folks who want to operationalize on this, I always think

about creating a little bit of a framework in the beginning early on with some milestones along the way that you can actually measure. That way, let's say I start out and say, okay, here's the features of say, freemium and then premium. Here's the dates by which we want to have X number of customers. And if these things start to not happen the way you originally thought, well, then you have at least some framework by which you can self-correct. What I find many times is people sort of blunder into the unknown without knowing really where they're going, what their pricing is, what their go-to-market is, and then they're sort of in the middle of the forest saying, well, like, this isn't working.

But, yeah, I think part of that's they, they expect the customer to tell them. Right. Versus, right. Understanding they're going to have to go. Right. Maybe guide the customer. Exactly. That's very important.

Like, oh, well, we'll just let the customer decide. Customers don't really, customers know. They've never bought this stuff. before. And they, if they've never bought or used something and you want to have an innovative product, what do they know? And so we, I mean, one of our investment criteria and looking for entrepreneurs that we want to back is do you have a real feel for what the future of the market is going to be? And you got to believe in yourself and got to believe in that vision. And then you have to educate customers and bring them to you. And that's where the sales and marketing

organization comes in is, you know, to be able to guide, to help guide that customer. or to help them with the criteria. You know, here's where we think it's going and here's how you can go. Thank you so much, you guys.