The following is a guest post by Andy Singleton. Andy is the founder and CEO of Assembla, a company that provides online workspaces for software teams, including bug tracking, repositories, and collaboration. Remember, as with all guest posts, the opinions and views of our guest bloggers do not necessarily reflect the opinions of OnStartups.com — but sometimes they do. – Dharmesh
Make The Cheapskates Pay
[I originally presented this material at Barcamp Boston. As the presentation went on, and tweets went out, the room got more and more packed. So, I know that a lot of people are interested in this subject. I wrote an outline for the presentation in five minutes just before the session, so it is surprising that this writeup has taken five months to compile, and has grown far beyond the usual size of a blog article. Some subjects are important enough to deserve 8 pages. Without further delay, I bring you “Make the cheap bastards pay.”]
Even being a cheap bastard myself, I made every possible mistake in selling to the rest of you.
My grandparents on one side were Scottish pennypinchers, and on the other side, Armenian rug merchants. They would be proud that here at Assembla we spend only 3% of revenue on general, administrative, and overhead expenses. Even fewer dollars go to pay for online services, although we depend for our commercial lives on the ones that we do buy.
And what about you? Do you pay for all of the services you use? How many of you use gmail or Google apps? How many of you buy the paid version? Are you a cheap bastard too?
We don't want to contribute our OWN hard earned money, but we should remember that it is important that our vendors maximize revenue, preferably from somebody else. This helps them deliver better quality for payers, and more services for non-payers. We want that better quality, and those extra services, so we should always give vendors at least moral support in their search for revenue.
My support will come in the form of cheap advice – this blog post. I have made a study of my errors and come up with some basic principles that might help you.
The number one goal: Maximize Revenue
The number one goal of your pricing strategy is to maximize revenue. That is what allows you to deliver more and more value to your free, cheap, and full price customers.
The number two goal: Reduce Cost of Sales
The number two goal is to reduce your cost of sales. That's why a lot of online vendors, Assembla included, offer free trials. It's a marketing tactic that reduces cost of sales. We give customers a chance to try the product, in the hope that they will figure out its value on their own, instead of forcing us to spend time and money explaining and persuading. In the bad old days, “enterprise” software companies would spend half their revenue on selling, and they would pass these costs onto customers. Eventually, customers figured out that they were paying twice as much as they had to, for something that had very little value once the software was installed. They started buy self-service products, and the enterprise software business began its long decline. For all those venture capitalists out that wanted to invest in “sales and marketing” - how is that working out for you now? How does it feel to invest in something that your customers don't want? These sales practices continue today. But, the general trend is to reduce the cost of selling, and increase the amount of energy you can apply to actually delivering a good product.
The number one sin: Not getting something from payers
The biggest sin is to not get any money from people who will pay. They won't respect you, and they won't get the quality of service they want, and you will starve.
When we first started charging for Assembla.com services, private workspaces were free, and we offered encryption and backup for $20 per month. We figured that if you were running a serious commercial project, you would want encryption and backup. We were wrong. One of my co-founders has a day job as a venture capitalist, and I remember that he called me after visiting a company where his group had just invested $1M. His report was “They use Assembla, and they love it. I wanted to kill myself because I knew they weren't paying anything.” We were committing the number one sin. Our free package was so seductive that we were leaving money on the table with customers that could easily afford to pay and needed the quality of a premium service.
Free is a lot different from cheap
This example shows the incredible power of free offers. Free is not the same as cheap. Psychological research shows that people will take a free option even if they really like the cheap option better. Some people rail against free offers saying that “free is not a business model,” and they are right. You don't have a business model until you get paid. However, free is a marketing technique that is so powerful that few can ignore it.
Users are predestined to be payers or non-payers before they register
Let's talk about what makes people cheap. Basically, they are born that way, or maybe deprived as small children. By the time people sign up for your freemium service, they are pre-sorted into “Will pay” and “Won’t pay”. You can't immediately tell what category a new user is in. The payers generally stay in the closet, but they already have needs, hidden needs of their own that will eventually provoke them into paying. There is nothing you can do to turn a non-payer into a payer. In the lifetime of the universe it might happen, but they aren't going to turn over a new leaf during the free trial period.
You don’t care about people who won’t pay. They have little impact on business decisions. They are just statistics, “traffic” to be “monetized” (or not). They are neither good nor bad. They are side effects. They are part of your marketing expense. You want them to be happy because all people deserve to be happy, and you want them to say good things about you, but they are not customers.
So, I lied. I don't have any secrets for making cheap bastards pay. Let them have their free fun. They can be useful to us, they can even BE us, but they won't pay us.
People who will pay are not statistics. Their lifetime value will be significant. That's why, when a paying customer calls Assembla, and nobody else is available, my phone rings, even when I am at home and getting ready for bed. I love my wife, but I get a cheap thrill out of that marginal $24 subscriber.
So, why do anything for free users? Once they get used to free services, we know they are not going to pay. In a recent survey, 0% of Twitter users said they would pay for the service. Free users howl with indignation if you remove services. They cost money for servers, bandwidth, and administration. They also cost money because they cannibalize from paying services. Some free users might be in the category that would pay – a direct loss of revenue. And, with the attractiveness of free offers, you end up getting a lot of these freeloaders. This seems like the worst of both worlds. You are losing money, and you are making it up in volume. For this reason, experts like Jim Geisman recommend providing free trials, but not extended free services.
And yet, the free offers just keep coming. Let's look at some reasons why.
Free users can attract or refer paying users
Free users can attract or refer paying users. They become a marketing expense, like a referral fee. For every X users that a free user introduces to your service, some percentage will be in the paying category.
This leads to some math. Free can be a terrible idea, or a great idea, depending on how social your free users are, whether they have paying bosses, and how many potential paying users they introduce to your service.
The Curious Case of the Reverse Volume Discount
A normal business selling widgets will offer volume discounts - $2 for one widget, $150 for 100 widgets, $1000 for 1000 widgets. Software is not a normal business. In enterprise software, and especially management software, you typically see a reverse volume discount, where bigger buyers, with more users, pay more per user.
Why? I notice three things about this situation:
* The most important factor is value. Managing a small group comes naturally, and you can do it without a lot of tools. Managing a big group is complicated and hard. If you can actually solve a hard problem, you can charge more.
* Cost of sales. Bigger organizations take longer to make a decision, they negotiate terms, they require more security and services, and it costs more to sell to them.
* Individuals and small groups are amazingly price sensitive about software.
The prices that small groups will pay is often small enough, compared to the value of enterprise upgrades and referrals that come out of small group pilots, that it makes sense just to go free.
In fact, many of Assembla's bigger competitors offer free services for the first five users. It's the most common type of free offer in our category. Prices then escalate as you increase the number of users and add various reports and workflows that are useful only to bigger groups. It's a strong business model, and I recommend it to any vendor that is willing to make an investment (higher cost of sales!) in selling bigger packages for real money.
More reasons for free offers
Product testing: You need a lot of users to test new features, so you do a Free Beta. It makes sense. It's a good trade between consenting adults.
Traffic: Maybe you can make money off advertising, and this works better if you get more traffic because of free offers. Even if you don't think advertising is relevant on your site, you might run experiments to see how people respond to variations of your own offers. Yes, if you visit Assembla.com, we run experiments on you.
Accident of history: A lot of Web services don't start out as products. They don't have a pricing strategy, billing infrastructure, customer service, marketing, etc. They are just things that you share on the Web, maybe things that you use yourself. That's where Assembla started.
Give back: Most vendors in Assembla's category offer free services for open source and community projects, and many also contribute code. This is great marketing. Open source projects attract a lot of potential customers. However, most people would provide services and code anyway, to give something back to communities that give us a lot of value.
So, we might have good reasons for making free offers. But, we can't sustain them unless we also have a pricing plan for our paying customers. That's where the mistakes pile up.
Ask “What is the minimum we need to deliver?”
We were working completely backward on pricing the non-free stuff. In my mind, I was asking users, “how much do we need to deliver to get the price we want”. We kept adding. This is completely hopeless. It was my worst mistake. The answer is basically that there is little you can do to move the customer to pay your price. When they sign up, they are predestined to pay $0, or $X, or $Y. They set the price, not you. Anything extra that you throw in doesn't help you.
The smart guys in SaaS pricing ask “What is the minimum we need to deliver to get the price the customer is willing to pay.”
If you offer customers a minimum package that meets their needs, that package won't steal business from the more generous customers. This is especially important for your $0 offer. And, some argue that customers appreciate the simplicity of NOT getting extra stuff in their package.
Assembla doesn't follow this advice very well. We give away a lot of stuff in our basic bundle, but we're always trying be stingier (I mean, simplify and improve our model).
The metered pricing mistake
The next mistake we made was metered pricing, and this cost us probably half a million dollars before we corrected it. We were coming from a free service, that we had offered just to get to know programmers. We knew that asking for payment would be a shock, so we wanted it to be cheap. We offered our services for $2 per user per project. We called this “metered”. Every month we would bill you only for the users and projects that you actually used.
What happened? First, people complained bitterly. Cheap was more expensive than free. Second, a pretty high percentage of them bought the service after we made it a requirement for “private” permissions. They did need the service, and they were much more willing to pay for privacy than security. Third, they immediately went to work removing users, removing projects, and relentlessly reducing our average selling price. It got to the point where the average subscriber was paying for less than four users. They went crazy trying to save themselves $2. It was totally irrational. I would spend 15 minutes on the phone with a guy who makes $100/hour to figure out how to save $2.
People hate to make purchase decisions. They hate to think about spending another $2. It doesn't matter if the money is noticeable. It still hurts. They hate to make purchase decisions even for one penny. That's why micropayments never go anywhere.
I actually knew this before I burned the half million bucks that I needed for the kid's educations, because in the 90's I worked in the “retainer advisory service” business. We were selling services (Gartner is one you have probably heard of) where the customer pays for advice and reports. We learned that they would never pay for just one report, no matter how cheap. Instead, we would sell them a big bundle of reports and advisory time, most of which they would never use, that would cost at least $20K, and they only had to decide once per year, and this made them feel better. As the guy building the online version, I figured out that I could deliver profits by delivering even bigger bundles, in the form of online “enterprise licenses” for everyone in the client company.
Not only do people hate purchase decisions, they also hate uncertainty. Assembla metered customers called me to tell me they were unhappy, uncomfortable with the idea that they didn't know how much they would pay each month, and how they wished they had the certainty of fixed price bundles.
When we came out with fixed price bundles, our average selling prices jumped up. But, the most surprising change was in customer satisfaction. Even though our new customers were paying significantly more, they were also significantly happier. They didn't complain. The money was small enough that it didn't matter. They could make the commitment and forget about it.
So, not only was metered pricing making us poor, it was making our customers miserable. It had negative value for them. They were willing to pay extra to get rid of it.
The right sized bundle
If the small purchases of “metered” pricing have bad effects, should we switch over to selling the biggest possible bundles? That's the approach that advisory services take. Salesforce.com is the most successful SaaS company, and they succeed by charging high prices (typically, $80 per user per month, compared with about $5 for Assembla or Google Apps), and by forcing the customer to buy for a full workgroup, a full year in advance. So, the bundles that they sell are big. The actual purchase decision comes to $1000 per user per year. They assign a salesperson to work with you while you make this decision.
Selling bigger bundles works against the goal of minimizing the cost of sales. You have to spend time and money to sell those big bundles. That pushes you toward smaller bundles that reduce the cost of sales.
Try this rule of thumb: The effort to move to a smaller bundle should be big enough that it is not worth a subscriber's time to figure out how to reduce usage to the next lowest package. You want to save the subscriber time.
But, metered pricing does work!
The rule against metered pricing is made to be broken. Actually, we buy a LOT of stuff on a metered basis. When I drive to the store, I don't think about burning an extra 70 cents worth of gas. When I leave a server running on Amazon EC2, I don't think about the $2 in charges I am going to incur by morning.
Why is a metered pricing a deterrent for online services, but not for cloud servers or gasoline? I can only guess. Maybe if the billing is in small enough increments, I stop thinking about it as a purchase decision. Somebody should do research on this.
They start by trying a commodity
I kept banging my head against wall because our customers were comparing us to some cheap competitor – often a barebones repository vendor, or an open-source ticketing tool. Why were they treating us like a commodity? We put a lot of time and thought into making distributed teams more productive, building a great solution for managing a project shop, repository alerts – browsing – builds, accelerating software development, selling MORE than a commodity.
What customers think they are buying is not what you think you are selling. At some point you have to forget what you wanted to sell, and rotate around to see what the customer is actually buying. We were selling a high value solution. In this case, the customers were buying the commodity, at least initially. When costumers start a trial, they don’t actually want something that is new and better. They want something that is easy to compare other products. They want to open three tabs in their browser, compare some similar offers, and make a choice.
Wouldn't you want the same thing? You want to be able to compare a product to competitors. You want to evaluate something that you understand. Buying a commodity makes you feel secure.
This observation had some immediate positive benefits. We stopped trying to sell the “benefits” and the unique “solution” on our Web site, and instead, we described specific features that customers could compare to competitors: ticketing/issue-management, repositories, and collaboration. It's the opposite of what most marketing people would recommend, but calls from confused prospects went down, and sales went up immediately.
Luckily, that's not the end of the story. It's just the beginning. Once you have satisfied the need for a commodity product, you can move on to selling the high value solution.
Customers often don't know the value of your product. To get an idea of how much it should cost, they “anchor” to examples. For example, they check your competitor's price. That's a good, logical way to figure out how much to pay, since in fact they can buy the competing product.
However, this anchoring effect is strong even when the anchor doesn't have any facts to back it up. Studies show that in negotiations, the first person to throw out an offer sets an expectation (an anchor) that holds, even when the other side knows it is an arbitrary negotiating tactic. Even expert appraisers are swayed by the asking price of a house.
Most vendors who sell products online use this anchoring effect in their presentation. If they are selling a set of bundles at different prices, they will position the bundle they want to sell in the middle with a “Most popular” or “Best Value” label. Just having the other packages serves as an anchor to validate the price and value of the middle bundle. Studies show that people prefer to buy the middle-priced option in a list. Vendors will try to pull you up a notch in price by adding even higher-priced bundles, which may actually be less attractive. The middle bundle (hopefully) looks like a bargain.
There are lots of other ways to use anchoring. For example, customers like a pricing plan that is similar to the plans for competing products, because it is easy to compare. You might be able to use this to your advantage, by offering a plan that is similar to your most expensive competitors, and not similar to the less expensive. This creates a point of comparison – an anchor – that looks good for you. For example, Assembla's more expensive competitors charge by the user, not by the project. If we offered a per-user plan, it would look cheap in that market, even if on average it was a price increase.
Use Anchoring for Good, not for Evil
Assembla isn't the cheapest option, but it is cheap compared with many competitors. It's very cheap compared with labor, or even the cost of computers, networking, and phones. It's extremely cheap if you think of the increased productivity. However, we frequently got complaints about price.
Here is the thought sequence that we uncovered:
1) I start by trying a commodity feature – repository hosting
2) I can get a subversion repository for $6/month with unlimited users
3) Therefore, Assembla is worth only $6/month
This is irrational. I could just as easily construct a sequence showing that Assembla substitutes for something that costs $1000/month. But, it is a sequence that a lot of users followed. Anchoring is not rational.
Commodity + Anchoring is potentially a bad combination. It can anchor you to the cheapest commodity. You need to manage what you are getting anchored to.
This argues for breaking out the commodity – repositories in this case – as a separate product with competitive pricing. What is competitive? I didn't see a big future in marketing a product with prices moving down through $6 toward 0. Our response was to offer basic repositories for free. This was an expensive move for us. We have great repository features, way better than the commodity hosts, and a lot of people were paying a premium to get them. In giving up some of that revenue, we are leaving money on the table . We also accept the hosting and storage and admin costs of handling hundreds of thousands of repositories in the future, at our promised commercial level of quality and reliability. But, by cutting the anchor loose, we have a bold move that makes a lot of people happy, generates traffic to look at our other offers, and gives us the freedom to price our other features closer to their actual value.
So how did free repositories work out?
Now, it is the competition that hears price complaints. Nobody complains about our prices. Not handling complaints is worth a lot to me.
By other measures, free-repo is a terrible free offer.
Conversion of free users to paid is low. Out of the first 10,000 people that signed up for free repositories, only about 1% have purchased paid subscriptions. Of the small number that tried the full-featured product, only about 15% of them ended up buying. Normally, about 50% of the people that start subscription trials end up buying.
Free-repo users have very small teams. They don't invite many colleagues, so the probability that a free user will introduce us to a paying user is low. And because these are free PRIVATE repositories, they don’t show up in search engines and get browse-by traffic.
You don't even have to use the Assembla Web app to use the repositories. You can just use your repository client. So, although we are providing servers, we aren't really influencing you as a user.
Free repositories cannibalize a lot of business. Assembla's repository features are good, and a lot of people will pay for them. So, we are cutting our own revenue with free repo.
Repositories are our most expensive and complicated feature. We invest a lot in development and administration of repository feaures, and about 2/3 of our servers are specialized repository servers.
We reserve the right to drop the free-repo offer at any time, as long as we continue to serve the people that already signed up (see below about “never take anything away”). However, I think that we will keep it. I'm stubborn that way.
An example of a good free offer
Free Standup is a great free offer: http://www.assembla.com/offers/standup/index2.html
It doesn't cannibalize. Nobody buys Assembla just to get the Standup report
It's immediately useful to almost anyone without any training
Standup is a management tool that you use with your whole team. The teams are bigger, and they include managers that tend to make actual purchases.
To use Standup, you log on to the Web site every day.
It is cheap to deliver. It is a simple feature that is part of the normal database app.
It converts. About 10% of free standup users will eventually buy.
The catch? No volume. People don’t know – yet – that they need an online Standup report. For every person trying free standup, there are 50 people that want repositories.
Never take anything away
In November 2008, we told our “free private” users that we were discontinuing free service, and that in the future they would need to buy a paying subscription. We were bombarded with disappointed, melodramatic, vituperative, ANGRY comments, claiming that we were doing something evil, sneaky, and fundamentally unfair. It didn't matter that we had worked nights and weekends for the previous two years to provide free services. Nobody thanked us for that, or for the free public services we continued to provide, or for the four months of additional free services that we provided for the transition, or for the low prices going forward ($13 per team on average), or the simplified export for those who wanted to take their stuff and go home. They had lost something, and they were angry.
People are always more unhappy to losing something, than they were happy about getting it in the first place. There is a word for this: Loss aversion - http://en.wikipedia.org/wiki/Loss_aversion
If I gave you a beautiful car to drive around for a year, and then showed up and took it away, would you be grateful for the free ride? No. You would be pissed off because I took it back. That's human nature. Psychologists have a way of testing this. Take $1 out of your wallet. Will you trade it for a 60% chance of winning $2, and a 40% chance that I am going to TAKE THAT DOLLAR AWAY? Most people won't, if it is put that way. We're totally illogical on this point. Monkeys are the same way, as demonstrated in this amazing video - http://blog.ted.com/2010/07/29/a-monkey-economy-as-irrational-as-ours-laurie-santos-on-ted-com/
So, never take anything away.
Make changes and raise prices for new buyers only
You must change your pricing. It's impossible to answer customer requests, maximize revenue, lower sales costs, and generally bring forth joy through innovation if you don't change your pricing. Phone companies know how to do it. They often raise prices, and remove options, but they do it only for new subscribers. They don't change existing subscription plans. You can usually keep your existing phone plan for quite a while after it has been removed as an option for new buyers.
I recommend the same technique. Change your options for new subscribers without bothering your existing subscribers. You should program your system so that it keeps track of all of your historical and current subscription plans. Then, it can continue doing billing for all of the old subscriptions, even while you add and change the options for new subscriptions. This buys a lot of flexibility, at the (minor) cost of having a more complicated billing program.
What about reducing prices? In the technology business, costs are constantly declining. You might want to lower your prices to compete for new customers. On the other hand, you might have a significant number of existing customers that are happy paying your higher prices, so if you lower your prices, you lose a lot of money instantly. I'm not sure if there is a right answer for this situation. Sometimes, you just have to take the hit to stay competitive. However, we do see some clever workarounds. For example, new customers often get X months free, or some sort of discount coupon, or faster servers, which are not available to existing customers. In the extreme case, the vendor will launch a new, cheaper brand to compete for new business.
Never take pricing advice from your customers
When we took away the free-private service and replaced it with the (admittedly flawed) metered plan, our users bombarded us with suggestions for alternate ways to price the product – more than 90 different proposals in all. In 100% of the cases, the proposals would reduce the amount paid by that user, transferring costs to a different category of user. Users with a lot of team members wanted to pay for storage, users with a lot of storage wanted to pay for team members, etc. Some of them tried the claim that my business would be totally, utterly ruined if users like themselves were forced to leave as the result of a misguided pricing model that forces them to pay more than $2/month - without stopping to think about how little money is actually lost if they leave. Not one user was able to go against the instinct of self-interest, and think about ways to raise enough money to guarantee a high quality service. In other words, not one single user out of 90 actually gave good advice. This is why you should not take pricing advice from your customers. They are smart people, and they can give you good feedback about what they like and do not like, but deep in their reptilian brains they are incapable of giving you pricing advice that will meet your goals.
Sometimes I see a new service that launches free, and then asks users for pricing advice. The advice is inevitably for incredibly cheap, metered pricing, and often, the vendor actually tries to follow it. Later this same vendor, gaunt from starvation, will need to confront the pitchfork wielding mob and ask for a price increase. LOL.
Pricing is like other aspects of product management. Customers can tell you what they want, but they are ineffective in telling you how to deliver it. It's your job to figure out how to deliver what they want. That's why they pay you.
Thanks go out to Jim Geisman of Software Pricing Partners for his insights.
Article has 44
comments. Click To Read/Write Comments
I’m going to open this article with a short (and true) story. I officially kicked off my marketing software company, HubSpot, about 17 months ago. If you’ve read my blog for any period of time, you likely know that I’m a big beliver in the “charge early, charge often” mantra. As it turns out, in order to “charge early”, you have to figure out what you’re going to charge people. That is, you have to have a price for your product. Thankfully, both my co-founder (Brian Halligan) and I had recently graduated from a top 5 MBA program. And, it wasn’t just any top 5 program — it was MIT. You know, that place where science and math and uber-geeky analytical stuff happens. So, you’d think that when it came time to figure out a price for our product, we’d really dig in, do some heavy-duty analysis, some really hard thinking and come up with a relatively well thought-out price. That’s not what happened.
When it came to deciding on the price for our software, we basically just rolled the dice.
I’d love to for the statement above to be an exaggeration. Surely, we spent some time pondering that oh-so-important factor in our business sucess. Nope. We didn’t. One of us (I think it was me) suggested “how about $250/month”, and that’s what we went with. And, that’s where the price remained for about 2 years.
Things turned out fine for me and HubSpot. But, you still shouldn’t do this. Don’t just roll the dice when it comes to pricing your product. Give it some thought, consideration and (gasp!) some analysis. Your first step towards this path should be to run over, right now, and get the book “Don’t Just Roll The Dice: A usefully short guide to software pricing” by Neil Davidson. Even if Neil weren’t such a nice guy (he is) and even if he doesn’t run my favorite conference (he does) and even if he didn’t build a really successful software company himself (he did), I’d still implore you to read the book. It’s got the highest value-to-length ratio I’ve seen in a business book in a long time. Go get it, right now. And, if you’re still not convinced, Neil’s even been nice enough to give it away for free in convenient PDF form. Yes, that’s right, you don’t even have to buy the freakin’ book on Amazon for $9.95 (though you could).
Just on the off-chance that I caught you at a particularly skeptical time and you’re still not convinced, here are some of my notes from the book.
Insights On Software Pricing From “Don’t Just Roll The Dice”
1. Your product is more than just your product. You might think that your software product is just the bits and bytes that your customers download (or access online), but you’d be wrong. What customers are actually paying you for is the entire experience of doing business with you. Everything from how you market and sell the product, to how you help people use it and how you maintain it going forward. All of it. Your pricing should be based on this reality.
2. There’s a difference between perceived and objective value. It doesn’t matter how much “real” (objective) value you have baked into your product if your customers don’t perceive that value, they are not going to pay as much for it. Hopefully, their perceived value is a function, to some degree, of the objective value. If not, you’re screwing something up.
3. Community matters. The group that your customers belong to, or want to belong to will impact the price they’re willing to pay. For example, some people buy hybrid cars not just because of the environmental benefit or the higher mileage but because they want to be part of that community. The same reason some people buy a BMW. Determine what kind of community you can build (or tap into) around your offering. Help people belong to the community they want to belong to.
4. As it turns out, people do buy drills (not holes). There’s the reasonably famous adage around “people buy holes, not drills”. The point is to focus on the benefit to the customer (not the product itself). I generally agree with that notion. But, it’s useful to keep in mind that holes can be a commodity, but people still sometimes pay $400 for a drill. Benefits are important, but the direct benefiit is not the only one that customers value.
5. The more differentiated you are, the more you control price. This one should be obvious. If you have a product that’s about the same as all of your competitors, then you don’t really set your price — the market does. Of course, nobody thinks of themselves as being identical to their competition (especially software companies). But, what we often forget is that it’s difficult — and very risky, to try and create a completely new category and be totally differentiated. Decide which dimension you’re going to differentiate on and make sure it’s reasonable given your particular constraints (like cash).
6. No battle plan survives contact with the enemy. This quote is not actually in the book, but I think it still fits the theme. When setting pricing, it’s important to consider what the “market response” is going to be — particularly if you’re in a well-defined category. Just because it doesn’t make economic sense for a competitor to get in to a price war with you, it doesn’t mean they won’t do it. Particularly if they’re big or well-funded. If you’re thinking about competing on price, keep that in mind. Better yet, don’t do it at all.
7. Remember to be fair. As humans, we often have a sense of what we think “fair” pricing is. Even though a particular pricing model is “theoretically optimal”, it might not be wise in practice. As software entrepreneurs, we often think we can get away with certain types of price segmenting simply because it’s enforceable in the software. Just because you can keep customers from doing certain kinds of things (unless they pay up), doesn’t necessarily mean it’s the right (optimal) thing to do. In the long term, it could actually hurt. Try to put yourself in the customer’s shoes and envision if they think the way you price things is fair. [Note: I’m not suggesting you be all rainbows and cupcakes and suggest that you price based on being “nice”. I’m just saying that you might actually make more money by being empathetic]
8. Pricing complexity has a cost. One of the things you learn in micro economics (and is discussed in the beginning of the book) is the concept of supply and demand curves and how you can segment your pricing in order to capture the maximum value (i.e. optimize revenues). This can be a wonderful thing. But, it’s critical to remember that this segmentation has a price — it’s not free revenue. For example, when HubSpot went from a single price ($250/month) to two prices (still pretty simple), life got a lot harder. All of a sudden, our marketing, sales and even our operational efforts got more complicated. The product got more complicated. All of our pretty charts that we used to talk about the business and measure success got more complicated. The reality is that when you add a new dimension to your pricing structure, you’re adding a new dimension of complexity. Oh, and by the way, the *second* price that you add to your product is the most expensive. After that (third, fourth, etc.) things get a tad easier because you’ve already built some of the infrastructure to support multiple prices. And by that point, your brain is already used to the pain.
Phew! I typed this entire article in one sitting while simultaneously reading a majority of the book for a second time. If I haven’t convinced you yet that you should go read it then I think I’m hopelessly inadequate at conveying the importance of this topic and the usefulness of the book. Or, maybe you’ve already got it all figured out. If so, may the wind be in your sails and may you go forth and prosper. For the rest of you, just download the book.
And, on a more selfish note, what are your biggest insights when it comes to software pricing? What challenges have you dealt with? What questions do you have about pricing your software? If you’re looking for some great answers, you can post a question on Answers.OnStartups.com where a bunch of smart folks like Neil Davidson (the guy that wrote the book) hang out. Hope to see you there.
Article has 62
comments. Click To Read/Write Comments