Pricing models, the freemium myth and why you may not be charging enough for your product

I’ve been pulled into a number of product and pricing meetings recently (for reasons unknown I’ve become the Foundry pricing and productization guy). I thought it would be helpful to put some of my thoughts into a blog post and hopefully spur some conversation in the comments and over email. With any broad topic, there are always exceptions to the general rules. There are also few absolutes and much of this advice varies depending on your specific product and market. And keep in mind here that I’m dealing generally with web services of some kind in the advice below (not consumer apps and not enterprise software). With those caveats, here are some ideas on pricing models:

– Beware of too many pricing tiers. Relative simplicity is helpful in many things related to building companies and pricing models are no exception. As it relates to pricing tiers, I favor fewer pricing levels. More tiers = more complication = more confusion. It also makes you more likely to violate some of the other ideas below. I generally like 3 or 4 product tiers plus one “call us for enterprise pricing” tier.

– Have a clear delineation between product tiers. Many companies initially offer a base level that includes all of the features of their product and then offer a little more of each feature at various incremental pricing levels. For some relatively straightforward services this can make sense (think Basecamp where your sales pitch is about offering more of a relatively defined thing, that everyone pretty much understands and values, and generally will want more of as they use the product more). For most products, however, this is a bad idea. For starters, most companies vastly overestimate their prospective customers’ ability to understand the features of their product (thinking the value of each feature is self evident). It also complicates the buying process as prospective customers try to figure out how much of each of those great features you’ve developed they want, and doesn’t create clear delineations between pricing tiers. While there are some features in almost any product that need to be priced this way, I generally favor opening up some number of completely new features with each pricing increment (say an analytics layer or workflow module, etc.). This has the side benefit of giving you lots of nice ways in your product itself to promote higher tiered features (think grayed out features – “click here to upgrade!”). It also makes the upper tier value propositions relatively straightforward – want X feature? You’ll need to purchase the Silver package for that.

– How about overlay features that you charge by the drink for? Many companies have parts of their product which some advanced users may want to access at every product level (API level access being a pretty obvious example). In these cases (and to be clear, these should be product features that a subset of your customer base is looking for – if not, they should likely fall into your regular pricing tiers) I think it’s fine to have an overlay where you charge incrementally to the base price of each tier ($X for every 1000 API calls or something similar).

– Be careful what you put a tariff on. You should understand very clearly what drives your own costs as you start to matrix out your pricing so you know what user behaviors cost you money. You should also understand (by talking to early users) what drives customer adoption, usage and lock-in of your product. And with all that in mind, be careful what you chose to put a tax on. There’s no hard and fast rule here and this is a nuanced conversation that’s hard to generalize and put into writing. But remember that your pricing will effect your customer’s behavior around your product. And I’ve found that many companies make the mistake of charging for features that are the key lock-in points for customers in their early use of a product and in so doing actually limit their likelihood of getting enough value out of the product that results in their becoming a long term user. To be clear, you should try to align (but not necessarily match exactly) customer value to customer cost. But not at the expense of lock-in. To keep on the Basecamp example, note that they allow for unlimited users at even the base pricing level. They (correctly) realized that while they could have easily charged for this they’re better off getting as many people in an organization using the product as possible.

– The freemium myth. I’ve been a great beneficiary of freemium models (as both a consumer and an investor) but I think for many companies the freemium model doesn’t make sense. If your product offers value out of the gate, if your service is such that it doesn’t necessarily benefit by having a large volume of users (and back-end data aggregation is probably not that benefit, which I point out since I often hear it used to justify fremium models for companies that in my mind shouldn’t have them), if you are selling largely to enterprises (companies) – you may not be the right candidate for a freemium model. I know it’s in vogue and I know that your product is so cool if only you could get a million people using it you’d blow past the typical freemium upgrade rates of 1-3%. But in all likelihood if you’re offering a product of value that’s well thought through, well designed and well architected, you’ll make more money by simply charging for your service out of the gate. (Note that I’m really not talking about consumer oriented applications here, where freemium models tend to make more sense)

– Don’t be afraid to charge for your product. The other benefit of not going down the freemium path is that avoids another common mistake companies often make which is not charging enough for their product. When you’re jumping from “free” to “something” that something often needs to be relatively modest – after all you don’t want to scare customers off and you do need enough of them to pay something in order to stay in business. But the reality is that if you have a good product, many users who will pay “something” will pay more than you think for your product. Put another way, those that get value out of what you do get enough value to be willing to pay a meaningful amount of money for it. You may lose a few people at the low end, but many products have a lower price elasticity than their creators realize. I’ve watched many companies spend untold cycles trying to raise the price of their product after initially setting prices so low that they essentially commoditized what they do. It’s also worth noting that if you get it wrong it’s a lot easier to lower prices than to raise them. And to be perfectly clear, I’m generally not a fan of the $19.99 entry price point for a product/service sold to business users. You can charge more. And you should.

– Beware the long “trial” period. I’ve written about this before. I think most companies offer too long a trial period for their product. Just like most customers who will pay for a product will pay more for that product, most trial users who will eventually become customers at 30 days will do so at 14 days. The idea here is to give people enough time to see how awesome you are but not too much time to change their minds or to forget about you. There was a great debate about this question when I wrote about it last time and I still haven’t found any academic research to back up my hypothesis, but that’s my opinion.

Hopefully some of these ideas will be helpful to you. Maybe a few will be provocative (as always, let me know!). I do recommend that companies working on their product pricing matrix spend plenty of time with customers to understand how they are using their product. It’s also helpful to bounce pricing ideas off of not just your early customers but also some trusted advisors who are not as close to what you’re doing. Getting a fresh set of eyes on your feature set is a good way to avoid drinking too much of your own cool-aid when it comes to your view of the ease with which potential customers will understand your value and pricing matrix.