In my previous post, I discussed the various methods SaaS companies use to price their products. I also discussed how Value-Based Pricing is an appropriate method to price SaaS products. In this post, I’ll cover the fundamentals of Value-Based Pricing, and also how I used this pricing method at BrowserStack.
Just to quickly recap, Value-Based Pricing enables you to price your product at a fraction of the overall quantifiable value (in $) you deliver to your clients. So if the customer is able to save $100k in costs per month because of your product, you could charge the customer $10k per month for your product if you go by the Value-Based Pricing mechanism. In this case, we decided to price our product at 10% of the value delivered. In general, SaaS companies tend to use the 10X rule where you deliver at least 10X RoI on the customer’s investment in your product.
Let’s now look at the step-by-step process you can follow to create pricing plans using the Value-Based Pricing method.
Step 1: Segment Your Customers
As a first step, you need to segment your customers into a few logical segments. The objective here is to understand the needs of each of these segments and the value they derive from your product. You will then be able to create pricing plans that suit each of these segments. Generally, SaaS companies tend to have 3 to 5 segments that they build their pricing plans for.
You could segment your customers based on one or more of these parameters — Size of team/company, Industry, Role/Function etc. As an example, if you use Size of company as a parameter to segment your customers, you might end up creating pricing plans for the following segments: Freelancers (1 employee), Startups (2 to 100 employees), SME (100 to 500 employees) and Enterprises (500+ employees).
Step 2: Understand the Value You Deliver to Each Segment
The value your product delivers to each of these segments will be different. If you have Freelancers and Enterprises among your list of segments, the value that a Freelancer would derive from your product will be completely different from the value that an Enterprise would derive from your product.
In order to understand the value you deliver to each of the segments, you need to invest in customer development. You should ask your customers questions such as how are they solving the problem currently, how much time does it take for them to solve the problem, what are the infrastructure investments they have made to build the solution etc. Through this exercise, you will be able to quantify the value (time saved, money saved or money earned) that each segment is able to derive from your product.
Your pricing should then reflect these differences. The pricing plans for each of the segments will be different in terms of the actual price and/or the product feature set provided for each segment.
Step 3: Price the Product for Each Segment
If we go by the 10X rule, ideally your product should be priced at X so that the RoI for the customer is 10X. Therefore, if freelancers are able to save $100 per month from your product then your Freelancer plan could be priced at $10 per month. On the other hand, if enterprises are able to make $10k per month because of your product, price your Enterprise plan at $1k per month.
Please note that the 10X rule is just a guideline so that you can be sure you’re not undercharging or overcharging for your product. If the value delivered is $1k per month then it makes no sense to charge $500 per month for the product. And if the value delivered is $1 million per month, then you would be undercharging if you price your product at $500 per month.
The 10X does not necessarily have to be 10X. It could be 8X, 10X, 12X etc. depending on what you feel is right. If the value delivered is $1k per month, then you could choose to price your product anywhere in the range from $80 to $120, as an example.
How We Created Pricing at BrowserStack
BrowserStack has a product called Live that enables people to manually test their website across various desktop and mobile browsers. One of BrowserStack’s core segments comprises of manual QA analysts. There could be single or multiple such manual QA analysts in a team based on the size of the company, maturity of the business etc. Therefore, one of the basic pricing plans we wanted to create at BrowserStack was for a manual QA analyst in a product team.
Now let’s look at the value that a customer derives from BrowserStack. The two biggest benefits that BrowserStack provides this QA analyst or the team that the analyst works for are:
- Time saved in setting up and maintaining virtual machines (and/or an extra computer), OS and browsers for testing on desktop browsers
- Money saved in purchasing mobile devices for testing on mobile browsers
To convert these benefits into a quantifiable value, we need to breakdown the time and money savings above into a few line items as below:
- Cost of purchasing 2 mobile phones per year to test on mobile browsers: $1,000
- Cost of purchasing 1 extra computer per year to test on desktop browsers: $300
- 3 hours of time spent per year in installation of virtual machine, OS and browser: $600 (assuming that per hour cost of the QA analyst is $200)
- 2 hours of time spent per quarter in maintenance and upgrade of virtual machine, OS and browser: $1,600 (assuming that per hour cost of the QA analyst is $200)
Adding these items gives us a total quantifiable savings of $3,500 per year. This means that if the team (or the QA analyst) were to use BrowserStack, it would save them $3,500 per year at the minimum.
So how much should BrowserStack charge such a customer? Going by our 10X rule, this would mean $350 per user per year (or $30 per user per month). This cost estimate of $3,500 per year is rather generous. If we were to be conservative, the estimates could even double to be as high as $7,000 per year, as a result of which BrowserStack could charge even more.
So how much does BrowserStack actually charge? As a matter of fact, pretty close to the numbers above. For its basic plan, BrowserStack charges $348 per user per year (or $29 per user per month).
If you notice the pricing above, you’ll see a new pricing parameter being introduced called per user. In order to have more QA analysts test on BrowserStack, a customer would need to purchase higher plans for more number of users. The pricing scales based on the number of users, which brings us to our next topic on Value Metric.
Value Metric
Value Metric is the basis on which you charge your users. BrowserStack charges its customers on a per user basis. Zendesk charges on a per agent basis. Stripe charges on a per transaction basis. Mailchimp charges on the basis of number of subscribers. WebEngage charges on the basis of monthly active users.
For any pricing plan you create, you should be diligent in your selection of value metric. The value metric you choose should adhere to the principles below:
The value metric should be easy to understand by the customers
A Zendesk customer knows the number of agents it has and so it knows which pricing plan to subscribe to. A WebEngage customer knows its number of monthly active users. If WebEngage was to start charging on the basis of number of actions performed by users, would the customers really know the number of actions their users would perform? Probably not. If BrowserStack was to start charging based on the number of minutes used, would the customers be able to estimate at the start of the year, the total number of minutes of testing time they would need on BrowserStack? Probably not.
In all the examples we discussed previously such as Zendesk (per agent), Mailchimp (per subscriber), Stripe (per transaction), BrowserStack (per user), WebEngage (per monthly active users), we can see that the customer is able to understand the value metric easily and is also able to quickly identify a relevant pricing plan that suits their needs.
The value metric should align with the customer’s need and should scale with usage
If a WebEngage customer has been on exponential growth curve with their monthly active user base doubling every few months, the cost of WebEngage for this customer should consequently increase. If a Zendesk customer were to add more agents, they should be required to upgrade their plan. If a BrowserStack customer was to get more QA analysts to test on BrowserStack, they should be required to upgrade their plan.
If your value metric does not scale with usage, then you would end up undercharging your customers massively. Please remember that it’s always easier to increase your revenues from your existing customers than by acquiring new customers.
This concludes my article on how you can create pricing for your SaaS product. I must thank the good folks at PriceIntelligently who have vastly improved my knowledge of pricing for SaaS products through their essays and eBooks.
