SaaS startups come to life from their founders’ strong product vision, which leads to deployments with pilot customers, which, hopefully, lead to paid service and wider roll-outs. In parallel with the product evolution, the commercial team’s thinking changes from “charging as much as we can get away with” to a more deliberate pricing strategy. And this is where it gets difficult.
It’s not always obvious how to determine what to base your pricing on — and much less how to communicate this to customers. Most SaaS startups start by pricing their product “on a per-seat basis”. However, for some, that is not the right business model. Let me use a flashback to my early days of working on the sales team at Dropbox to illustrate what I’m talking about:
Dropbox for Business pricing: $15/user/month for a team starting with 5 users and 1TB space (I am aware this has changed… I’m talking 2013 here). Two different customers call in trying to negotiate discounts:
Customer X: “Hi! We are 10 people, but we don’t need 1TB of space. Can we get a discount?”
Customer Y: “Hi! We could use the space, but we’re only 3 people instead of 5. Can we get a discount?”
As you can see from the example above, the criteria you use to communicate pricing to customers quickly become the basis for negotiations. At best, ineffective communication of value creates extra effort for the sales team. At worst, significant amounts of money are left on the table.
Pricing should be tied to the value customers are getting out of the product. What we are looking for is the “unit of value” that fits well with the offering of the business. For some, Salesforce most notably, one license or seat is that unit of value. However for those where value can’t simply be tied to one user, per seat pricing might not be the right unit of value.
But what are the alternatives to the standard way of pricing per seat? My goal is to share some thoughts on this based on conversations I had with my colleagues, various SaaS investors, and management teams.
The “Price per License” Fallacy
To highlight the “price per license” fallacy, let’s think of an e-commerce middleware software company, connecting front-end application with accounting and back-end systems. Initially, the company was pricing its product based on the number of seats. However, once the management team conducted a detailed analysis of product usage vs. price paid by different customers, they realized that the number of seats was not the right unit of value. Two different customers could pay vastly different amounts despite the same GMV going through the platform. The company subsequently moved from “price per seat” to a pricing model based on both GMV going through the platform as well as the number of admin accounts and realized a significant revenue uplift from the existing customer base.
When introducing a matrix pricing structure similar to the approach taken by the e-commerce software company, keep in mind that adding multiple dimensions to pricing introduces complexity. This makes it hard for the sales force to communicate value to customers. Before implementing a two or more dimensional pricing structure, the whole team needs to be crystal clear about the value customers are getting from the product and the sales team needs to be able to communicate it. Otherwise, the sales team will be pressed in negotiations. A good example of successful matrix pricing is a recruiting software company selling automated candidate testing solutions. Serving both SMBs as well as large enterprises the company struggled to find a pricing model that suits both and doesn’t leave money on the table: Should pricing be based on the number of candidates, tests or recruiters? After a long experimentation process, the company settled on a multi-dimensional pricing model. For enterprise customers, the number of sites, number of employees and expected new hires determine pricing. For SMBs, the number of tests forms the basis for pricing.
The Tiered Pricing Approach
Tiered pricing based on usage is popular with SaaS startups. Dropbox, Atlassian, Twilio, all have some form of “basic, pro and enterprise” versions of their product. Unlimited usage is usually a feature of the product’s enterprise edition. However, we think there are rarely cases where unlimited usage doesn’t leave money on the table for the startup. This may sound a bit counter-intuitive, given that hosting cost is almost negligible and other marginal cost of delivering software is zero. In practice, when a customer on an unlimited package increases usage by 2x and price stays the same, all additional value created is captured by the customer (and none of it is captured by you). And conversely, if your customers don’t take advantage of unlimited usage, they may try to negotiate the price down based on this metric (as in the Dropbox example).
One of the reasons usage of the product can increase dramatically is because your clients are “hacking their way” into new use cases for the product. For example, the recruiting software company mentioned above saw some of their clients use the software to evaluate the skills of its existing workforce and train new hires rather than purely for the purpose of evaluating new hires. It’s a wonderful validation for the product! However, on the commercial side, since the customer believes they bought the unlimited version, it will be hard to renegotiate the contract for appropriate pricing now that there are two products in use. In those situations, the best advice is to get your product and user research teams to work closely with the customers hacking the product and evaluate whether there is potential for an additional stand-alone or add-on product to be launched based on the newly discovered use case.
Another great way to capture value is by adding micro-services to the platform. One example of this would be payment processing for e-commerce software, e.g. Shopify. Those easy to consume add-ons increase the stickiness of the product and usually “fly below the radar” of purchasing departments in enterprise buyers.
At the end of the day, a clear understanding of the unit of value is the necessary first step before deciding how much to charge for “1 unit of value”, i.e. set your pricing. Finding that unit of value is not trivial. All parts of the company, from founders/CEO to product, marketing, and sales teams, should be involved and it should be regarded as part of on-going strategy assessments. After initial pricing decisions, you should monitor the market and customer behavior continuously to make sure that your startup is not undercharging.