Wednesday, January 27, 2010

The Basics of Software as a Service Pricing

It is pretty unanimous that software pricing is one of the hardest parts of a product manager's job. Whether it is an iPhone app or an enterprise software suite, pricing is frustrating to get right and has a major impact on the success or failure of your product. Unfortunately, nobody has come out with a simple, fill-in-the-blank spreadsheet, either.

I want to talk a little bit about software as a service (SaaS) pricing. The vast majority of applications being created, especially in the consumer market, fall into this category. Even many mobile applications tend to have a SaaS component associated with them.

To understand how to price software, it is good to get a handle on the economics behind it. Joel Spolsky's Camels and Rubber Duckies is a great article on the economics of software pricing. Eric Sink's Product Pricing Primer adds to those basics.

What I'm about to say is actually very basic. I had thought that it was common knowledge, but I recently worked with a company that did not have this basic understanding. As a result, I'm going to outline the basics of SaaS pricing.

Basic One: Pricing cannot be an afterthought

With traditional software delivery (e.g. CDs, DVDs, implementations1, or even downloads), you had a binary relationship with the customer. Either somebody purchased or they didn't. The bit may have flipped slowly with timed trials and sales cycles, but it was still a single bit.

The world of SaaS software has changed that. People expect tiered software, with useful functionality at every tier. While you don't have to decide how much a tier will cost right away, you do need to be designing those tiers into the product from the start.

Basic Two: Consumer applications need the Two F's

Free: A large chunk of your users will expect to never pay for anything. If you need large numbers of users for any reason (a social environment, viral marketing, whatever), you need to provide a free version of the application. If you can find a way to monetize these users (basic ads, affiliate programs, etc), great, but you have to provide a no-out-of-pocket, not-blinded-by-ads-or-other-garbage version of the application.

Functional: Providing a free version of your app that doesn't actually do anything useful is the same as not providing a free version. End user expectations have changed, thanks in large part to companies like Google who "give away" so many useful applications. Users will toss free applications that don't do anything. If people toss it, they aren't telling their friends about it or upgrading to the pay tiers.

Basic Three: Differentiate business from consumer

Business applications don't have to have the Two F's. Because of that, if your app is a business app, you want to make sure it is positioned as a business app.

Take a look at the signup page for 37 Signals' Base Camp product. Base Camp is a project management application, targeted at the SMB market. You can find a free single-project plan with very limited functionality, but you have to really hunt. If you didn't know it existed, you would likely miss it altogether.

Because it is people (who are consumers) who do business purchases, you have to make sure to make it clear that yours is a business product. If you confuse the buyer, she is likely to slip into consumer mode and think your app should be free.

Basic Four: Charge as quickly as possible

Only you can decide how quickly you can charge, but you want to charge as quickly as you can. 37 Signals didn't wait until they had a massive following to try to figure out how to "monetize" BaseCamp. They charged from day one.

It's about more than just getting revenue (as important as that is!). It's about ensuring that your users are attaching a value to your product. The longer your product is free, the more difficult it is to change users' perceptions and get them to pay later.

Basic Five: Test and measure, measure and test

Pricing is not static. Neither are the inputs that bring users to your application. Neither are a million other variables2. You should always be measuring and testing. Make sure you know what the impact is when you change your prices slightly, alter what features are available in the free version, or do anything else.

Eric Ries wrote a great article about what you should be measuring. Eric's Startup Lessons Learned blog is a great resource for figuring out what to measure, how to measure it, and what to do about what you've measured.

Basic Six: It isn't worth money just because you built it

The final basic is really an economics basic. Just because you've spent a lot of time and money building something doesn't mean it has value to your customers. It is easy for product managers and executives to think "this cost X dollars to make, so we have to charge X/N for it."

Unfortunately, that kind of thinking will not optimize your pricing and may drive away those all important users. Pricing is ultimately determined by the value the customer places on your software. Your business' viability is determined by whether you can produce the software at a price customers are willing to pay. Your job as the product manager is to ensure that value exists.


There you go. Six basic rules that will give you a foundation for how to price your SaaS application. Still no answer on whether it should be $9.95 per month or $12.95.


1. "Implementation" is just a fancy word enterprise software shops use when their software is so hard to install that their services team has to do it...and charge you for it.

2. Hence the name variables.

Image credit: David Neubert


David Locke said...

Add to charging as quickly as possible, add as invisibly as possible. Paying subscription fees should happen unconsciously.

Stewart Rogers said...

Great post!

johnny5alive said...