Pricing your SaaS Product and how we did it at Sosio

In case you aren’t updated on the current affairs, 2014 is shaping up to be a controversial year; and we’re not referring to Justin Bieber’s antics, Mr. Kejriwal’s dharnas or Mr. Modi’s development stories. Instead, a new contention is brewing in the annals for us which is every entrepreneur’s one of the worst nightmare: deciding how much to charge for your product ;-)

Pricing is one of the most difficult things to get right. There are several questions that come to us, and its good if we can get an answer for each of them. Should my MVP be free? When should I start charging? How much should I charge? Will I lose my first customer, if I start charging higher? Will the freemium model work?

We get into these FUDs(fears, uncertainties, doubts) because whenever you ask for money, there is friction, which cannot be removed, it can only be minimized. The best way to overcome these objections is to prevent them from happening. Well, I tried to study, how other people, were addressing the same problem, and tried to come up with one for my own product. Its taken more than 6 months, and hours of brainstorming with few of the amazing folks for me to reach here. I will try and summarize few of them.

The trouble with software pricing

Pricing is a basic economics thing. Unlike traditional manufacturing products, where there is a fixed cost of raw material, labour, transportation etc. a cost price for each unit is pretty clear. On this objective value for each of the unit, the sales team, tries to create a perceived value of the product, based on reference points of competing products, and after a basic survey of the demand curve, a price point is generally arrived.

For softwares, the case is slightly different. After break even, the price of a new unit, tends to be negligible. So defining an objective value for each unit becomes tough. Chances may be, the product you are creating may not have a direct competitor, or if there is an alternative it might be free. In that case, extrapolating from a reference point becomes tough.

The price tag you put on your software, is one of the most challenging thing to get right. Not only, it keeps you in business, it also signals your branding and positioning. Iterating on the product, is far more easier than on the price. Lowering the price is generally easy and appreciated but it takes to be an Amazon to demonstrate it profitably. Increasing the price, is tough, because it adds to the churn. So doing the most you can, to get it right, generally accounts for a successful business in making.

Addressing few of the initial Questions

Should I charge for my MVP?

Despite validating the problem that I was solving, and clearly mentioning the price point during the customer interviews in my initial stages, I used to be afraid of asking money for the product, because I had a fear, the product is not ready, the Minimum Viable Product was minimal, I was not sure of the hidden bugs and I was not sure, how deeply have I solved the problem.

The two thought leaders Steve Blank and Sean Ellis had the following to offer -

Steve mentions pricing to be one of the important questions in your customer interview, this helps you validate that the product’s value proposition is compelling enough for them to pay, and the problem is worth solving. Once the MVP is built, Steve asks you to sell it to your early customers. There is no clearer customer validation than a sale.

Sean Ellis, removes pricing to the post-product/market fit stage:

“I think that it is easier to evolve toward product/market fit without a business model in place (users are free to try everything without worrying about price). As soon as you have enough users saying they would be very disappointed without your product, then it is critical to quickly implement a business model. And it will be much easier to map the business model to user perceived value.”

Well both of them have their own merits. So I did an A/B with my customers. I offered two of them, the software for free, and mentioned to the other that we will be charging. The folks who were given free product, did not use it and it got shelved, whereas the ones who were paying, had feature requests, reported few of the bugs they came across, solving these bugs, and responding pro-actively helped me develop better relations with them. The free users asked for additional features, whereas the paying users asked for improved features, which eventually meant a better product.

Personally, I align more towards Steve’s side, because, the best validation you can get for products value prop. is the customers’ bucks, and if it gets figured out initially, nothing like it.

Should I go for a freemium model?

Lincoln Murphy has a white paper on The Reality of Freemium in SaaS which covers many important aspects to weigh when considering Freemium, such as the concept of quid pro quo where even free users have to give something back. In services with high network effects, participation is enough. But most businesses don’t have high enough network effects and wrongly chase users versus customers. The notable point in the above paper is - “Freemium is a marketing tactic, not a business model.”

People have struggled with freemium, and dropped it, with few exceptions of Wufoo and FreshBooks. The conversion for free to paid accounts has been relatively low even for Pandora, Evernote, and MailChimp. 37signals has greatly deemphasized their free plans to almost being fine print on their pricing pages.

Its not impossible to launch successfully with a free plan but things can get easy, when we simplify freemium, not look at it as a business model, with the only objective for it being to get people using your product in a manner that makes them want to pay for more advanced features.

What should I consider while pricing my software?

There are a number of ways to approach this problem.

The amount of money a customer is willing to pay, primarily depends on the following two factors -

  1. Value extracted from use of the product

  2. Emotional Willingness to Pay, which is an after effect of perceived value of the product.

And hence, two of the most obvious pricing strategies are -

Pricing based on the value provided

This is customer-first strategy. The amount of value each customer gets out of using Sosio, corresponds with the amount they pay us. Tried doing it, but devising an excel sheet, where in we could go and show, that you used sosio for X, and it increased your value Y times, is something, we are yet to find.

Pricing based on cost

This strategy takes care of our engineering team, sales cost, server and other rentals. This is generally intuitive from an engineering perspective. Pricing based on the number of accounts, the amount of data that is processed and saved, give us a good number, as to how much we should charge.

But the above approach makes it a uni dimensional pricing strategy. Our product is not just the product, its the customer support, its the number of users, its the problem that we are attempting to solve. The Quality of Support we provide, the response time of the support, Email Support versus phone support versus in person support, number of support incidents, product features and depth of usage are other metrics are other dimensions to reflect upon while deciding the pricing.

There are several params, to consider, and you can go on complicating your pricing and creating complex tiers. Even, I was doing one, till I read this post by Dharmesh Shah, and how he randomly arrived at a price of USD 250. I could have gone for a ballpark of maybe 20k INR, but here is how I arrived at what I arrived - I had few features, which other softwares, were providing as well. I have tied down features, uniquely, but my software, as of now, lacks the depth that these enterprise softwares offer, primarily for 2 reasons -

  1. those features will add to the complexity of the product and cost.

  2. the customer segment, I am targeting, does not require such depth.

What I tried was, brutally trimmed the price 10 times, of each of the features, and talked to customers. They were not willing to pay that much, but because I wanted to get started, I reduced it 50% further, the ones who were, happy, continued, the rest were a good bye.

With subsequent improvisation of the product, the prices will increase, and we will keep iterating on it.

Another advice, I got, while I was discussing my pricing strategy with Prof. Prem was to charge for the service and strategy. Well I don’t want to go into the details of how, an analogy can be if you are selling Adobe Photoshop, reduce the price of software, and charge for educational offers. It is working for me, two of my customers are happy with it.

Deciding a pricing tier

The four things to be taken care of, while deciding on pricing are -

  1. The price tier should be simple(Mixergy just uses the names of the plans as calls to action)

  2. It should be easy to compare, with the competitors.

  3. You should help people choose a plan.

  4. Avoid giving, too many choices. (The paradox of Choice)

An easy way of arriving at the tier is, creating customer persona, and segregating them.Your pricing tiers are a visual representation of where your buyers fit in your business model, and each tier should align to one type of customer.

Tiers makes sense for a lot of startups. But as of now, we are doing without it. Because based on the 50 customers I talked to during the sales process, most of them, got stuck, while I was explaining them the pricing model. If you’re a startup (or any software company) consider if your customers really need the additional pricing levels.

To end it all -

"Although scientifically purer, it often doesn’t make sense to change a single variable at a time. Theoretically, you shouldn’t change the price of your product, your discounting strategy and the types of bundle that you sell, all at the same time. But practically, it can be the right thing to do. It’s more useful to fix the problem than to understand why it’s broken. When a scientist goes on a blind date that doesn’t work out then, in theory, he should fix one variable at a time, and re-run the date. first, he should change the partner but go to the same film and buy the same flowers. Next, he should keep the partner the same, vary the film and keep the flowers the same, and so forth. but the pragmatist in him will, or should, change the girl, the film, the flowers, and buy some new clothes and shave too. If it works, he might not understand why, but at least he’ll have girlfriend." - Neil Davidson

And this awesome piece by Seth Godin -

Go ahead and act as if your decisions are temporary. Because they are. Be bold, make mistakes, learn a lesson and fix what doesn’t work. No sweat, no need to hyperventilate.”

Copyright Sosio 2014