What happens if one of your competitors drops their price by $5? How would it affect your conversion rates and Lifetime Customer Value (LCV) if you followed them down? What if a competitor increases their price by $5 and you need to follow suit? What would happen if you changed the features you offer in each version of your product? Or the number of users?

You don’t know. You can’t possibly know, And you don’t know because you’ve been building products atom-by-atom but selling them in buckets.

Pricing strategy has really been getting on my nerves lately. It should be on yours soon too, if it isn’t already. Why?

The cloud has ‘atomised’ software — you can’t point to cloud software and say “it exists here and not here” because ‘where’ it is changes, and you can access it anywhere. Thanks to APIs, sometimes the value of a unit of software isn’t in the product itself; it is more in the way one application interacts with another.

Also, the cloud has ‘atomised’ how we advertise, service and support software. You might buy your next SAAS product at a unique price that was offered to you and 99 other visitors by a dynamically served landing page generated by a tool like Unbounce,  after being exposed to a series of brand and offer messages planned and bought on hundreds of different ad networks, following you around as you use the internet with a re-targeting tool like AdRoll, using ad creative crowdsourced from hundreds of advertising freelancers competing for your business on Freelancer. 

A hot new startup like Geckoboard (whose pricing matrix appears above) probably couldn’t exist without the cloud. Geckoboard’s applications and data are dynamically distributed across a set of disks and processors that shrinks and grows according to actual customer demand.

It wasn’t always this way. Before web applications, it cost a lot of money to wrap up all the functionality of Geckoboard in a client software application, burn it on a set of CD-ROMs, ship it to you in a box with a fat manual and a serial number and then service you as a customer. It was making and selling software in ‘buckets’ — you needed to ship software via distributors and retailers, and if you could only be certain of selling three of the five copies of that product in a bucket, you’d have to price the three so that they’d cover the cost of shipping five.

With web applications — but before the cloud — the buckets got smaller. It still cost a lot of money to forecast and provision processing and data storage capacity. You’d just build more servers than you’d need, buy more bandwidth than you’d need, and wait with fingers crossed that the bill didn’t kill you when it came. The buckets were now a lot smaller than before, but software still had to be sold in large, inefficient units because your costs were incurred in large, inefficient units.

Today, in the cloud, the bucket’s been ‘atomised’ — once your software development cost is amortised, your cost of making another copy of your product and not selling it is effectively zero. You’re only paying for precisely the CPU cycles and bandwidth your web applications consume. You can plug that operating cost directly into your cost of customer acquisition and make sure you’re never crippled by your own growth.

You could, if you wished, price your product the same way — atomise your pricing so that your customer only pays for what they use.

SO WHY THE HELL DON’T YOU?

I blame 37Signals. Early in SAAS history they eloquently and persuasively argued that as long as you did one simple thing well, people would pay a monthly subscription price for it.

You don’t need to atomise your pricing, says 37Signals; instead you create a pricing table that manages pre-purchase and post-purchase cognitive dissonance by ensuring the product you should buy is bookended between one or more product choices offered at other prices.

You justify the cheaper products by removing features and/or limiting the number of users, and justify the more expensive products by adding features nobody will ever really want and/or allowing gazillions of users to access it. 

The customer looks at your 37Signals-style pricing table and he sees:

Not so bad, right? The customer gets the illusion of choice, congratulates themselves on being smart enough to know not to buy the Lame Version and too canny to fall for the ridiculously-priced version that comes with features they’ll probably never need. Maybe they’ll have to settle for the Super-Lame Version initially until they can get the boss to use his card to pay for the Version You Should Choose.

I see three problems with this, all growing at a rapid rate. Let’s address them in increasing order of importance to a young startup team:

1. Growing cost of cloud subscriptions. Each cloud product I subscribe to costs me between $20 and $50 per month on average. Annualised, it’s about what Microsoft Office used to cost me when it came on CD-ROM, only I had to buy a new version of Office only once every three years because Microsoft was so terrible at shipping products on time. Multiply that $50/mth by the 5-6 cloud products I need to subscribe to when getting anything actually done (because each is so lean, and focuses on a single pain point) and cloud software is getting increasingly expensive. When considering one product at $29/month, it’s not a big deal but if this is my ninth $29/month subscription, it could be one subscription too many.
2. Competition. If you’re a startup and you believe you don’t have any competition, it’s only because you haven’t read about them yet. Your competitor, and another five just like it, are all rolling down the same lean startup commercialisation runway as you, and hey: they’re also charging $9, $19, $29 and $199 per month for a nearly-identical product. If your competitors can’t get a 10x lead on features alone, sooner or later one will break from the pack and differentiate on price. When that happens, you don’t want to be anything other than the first to react or hold your pricing on the basis of a 10x feature gap.
3. Research. Ten times out of ten, when I sit with a startup team to quiz them on what they’ve learned from their early customer adoption, they’ll tell me that their data indicates [drum roll] the majority of new customers choose the Version You Should Choose, with significant minorities choosing either the Lame Version or the Super-Lame version, and either upgrading or unsubscribing sooner than those on the Version You Should Choose.
   
   Newsflash: you have learned nothing; you adopted a pricing strategy that gave the majority of customers no real choice over which features and what price they were prepared to pay.

What happens if one of your competitors drops their price by $5? How would it affect your conversion rates and Lifetime Customer Value (LCV) if you followed them down? What if a competitor increases their price by $5 and you need to follow suit? What would happen if you changed the features you offer in each version of your product? Or the number of users? Could you be charging $20 more per month than you do now and see the same Average Customer Lifetime and conversion rate?

You don’t know. You can’t possibly know, And you don’t know because you’ve been building products atom-by-atom but selling them in buckets.

Is there a better way? Really? Would I make you read this far if there weren’t? There is a better way, and it is this: to atomise your pricing.

Charge for your SAAS product the way you pay to serve it: in the smallest units you can. If you’re Geckoboard above, don’t sell big, inefficient buckets, sell tiny atoms of, oh, I don’t know, API calls, for instance. Make them vanishingly cheap, say, $0.000001 per call, give away the first 500,000 calls free.

Now (well, for a short time, maybe) you’re the only competitor in your space differentiating on price. You are meaningfully and significantly different. Your competitors will take time to consider and adapt to this new challenge, time you can employ to get lots of media coverage about your bold new pricing strategy.

You might get some grateful customers, relieved to see you at last offer them the same atomised cost efficiencies you’ve been benefitting from since you first signed up for AWS or Heroku.

Finally, you’ll actually learn something about how customers value their use of your product. No longer uncomfortably forced to squeeze into one bucket or the other, they’re free to consume your entire feature set, or not; free to make a billion API calls, or five; free to sign up the whole team of 750, or the whole team of seven.

A few months down the track you might actually have some meaningful bell curves, showing how many users a truly typical customer has, which features they use (and presumably value) most, and how many ‘product atoms’ they’ll consume in a month if allowed to consume as many as they need.

Maybe at that point, in a strategic masterstroke so deft your competitor’s heads will explode, you might have enough real data to introduce some fixed monthly pricing, in addition to your atomised pricing, strictly as an option to help fast-growing customers manage their budgets. But it will be lean, agile, well-researched buckets you introduce, such taughtly constructed buckets that they will fit your happy customers like the luxury bucket seats of a fine Italian sports car. That’s the kind of customer relationship they’d be mad to even consider leaving, the kind of brand relationship it takes more than competitors merely discounting or adding new features to make them leave.

Go now, atomize your pricing, and tell your new customers they owe me $0.000001.

- alan