Price your solution based on value, not based on what it costs to build.
Software is quite different to most products and services that we interact with in our daily lives, because the cost of distribution is close to zero, while with most real-world products, distribution plays an important part in setting the final price to the consumer.
If you buy fruit that is out of season, it will have normally been air-freighted from the other side of the world, and this is why they can cost a lot of money. After all, oranges literally grow on trees, but flying them five thousand miles and then delivering them to the store near your house by truck is where the real cost lies.
Software is just the opposite.
There is a real risk and cost to build it up front, but the distribution cost for one customer is as close to zero as you can get.
This means that when you price software there is a tendency to underprice it because any additional customers are essentially 100% gross margin. This can be a deadly mistake, because you still need to cover your operational costs and ensure that you can reinvest in sales and marketing to reach even more customers in the future.
When you're pricing software, especially SaaS (Software as a Service) there are lots of things to take into account and lots of different models, and today we will cover the most common ones.
Depending on your target audience, different pricing strategies will work better or worse. For instance, it generally doesn't make to offer fixed-price plans to enterprise customers as you do not capture enough of the value that your solution is providing, and this touches on the key message of this insight piece:
Price your solution based on value, not based on what it costs to build.
Before we jump into the different pricing methodologies, please keep the following in mind:
If you are venture funded, you should be optimizing for the fastest revenue growth, as this is what investors will be looking at. If you're self-funded, you can make principled decisions on pricing that would be impossible for a venture-backed startup to justify to their investors.
This is the simplest and most obvious pricing methodology. You sell one software product with one set of features at a fixed price, regardless of the number of users or usage.
This is often the best way to get started for a software startup because it will make your product far more accessible to a wider audience because it will significantly undercut the competition, and it also means you don't have to do much thinking about your pricing strategy... and neither do your customers! This type of pricing methodology is very easily understood, and it is exactly how we price our own Project Management Software:
As mentioned above, one issue here is that you end up giving too much for too little to large customers, as they will pay the same as your smaller customers.
In addition, because you are offering a fixed price, it can be difficult to sway customers over to your solution if price is an issue, while with other pricing methodologies it is easier to create a different plan or offer extra free users etc.
Per User Price.
This is what most fast-growing B2B SaaS startups use, and for good reasons too. Not only do you grow when you acquire new customers, but you also grow when your customers grow and add additional users to your software product, which can give you a double boost.
This per-user pricing methodology has the same benefits as the fixed price methodology, in that it is very easy to understand, but it does suffer some issues.
Charging per user can cause some customers to limit the adoption of your solution across their company because of the fear of ever increasing license fees, as each time they have a new employee there can be a multitude of software licenses that are required and this can really add up. SMBs (Small & Medium Businesses) are especially concerned with software costs as they grow.
It can also be argued that sometimes value is not actually linked to the number of users who have access to the system, especially if only a limited percentage of the users who have access actually need to use the product on a daily basis.
This is where there is a variation, made famous by Slack, where a customer only pays for active users:
At Slack, you only get billed for what you use. So you don’t pay for the users that aren’t using Slack. And if someone you’ve already paid for becomes inactive, we’ll even add a prorated credit to your account for the unused time. Fair’s fair.
Usage Based Pricing.
This works very much like your home electricity or water bill, where you pay for what you use. You take an underlining metric of usage, such as computing power for a server provider or number of leads for a CRM software, and your charge based on how much consumption your customer makes during a calendar month.
One issue with this pricing strategy is that it can be difficult for customers to estimate how much usage they will have and so it can make them hesitant to try your product due to the lack of transparency on the actual cost.
A great way to overcome this objection is to provide estimation calculators on your website where customers can input their predicted usage and see how much your product will cost them on a monthly basis.
Per Feature or Module Pricing.
This pricing strategy works well for consumer products, where the number of users is obviously not of key importance as normally there is only one user, and so you use feature to differentiate the different plans.
If the split between the features is created in an intelligent fashion, over time you should see a significant portion of customers upgrading to the next tier as they enjoy using the product and want additional features.
A variation of this is also possible for software that is sold to enterprise users, by offering a core product with optional modules as up-sells, which the customer can activate at any time by upgrading.
This is a great idea because when a large customer adopts a software this often means a change of process as well, and so by allowing them to buy your product module by module, you allow them to pace out the process change in their company in a slower, more manageable manner.
Ultimately, there is no correct way to price your software product, but it’s important to adhere to the following:
- Grandfather customers in. If you change the price, you should always attempt to 'grandfather' all your current customers with the old price, and only apply the new pricing to new customers from that day onwards. This boosts long-term client retention because they feel that they are getting an even better deal than they were before, while cementing reliability and trust in your service and ethos.
- Keep It Simple. The worst thing you can do is to make your pricing complicated. It’s already difficult enough to explain the core value proposition and features to a customer, and making them jump through hoops to understand how much it’s going to cost is just another obstacle in the way to a successful sale.
- Sell on Value. If you truly believe that your product will really help your customers, then make sure you price it that way! You’ve likely spent years building it and invested a lot of time and money into creating something special, so make sure that you’re rewarded, and where possible show customers how they can claim a great ROI by using your solution.
If you ever have questions about how to price your software product, feel free to reach out to Mäd and we can help you make one of the most important decisions you can make as a business owner.
Request a Proposal.
If you would like to #workwithmad then send us an email at email@example.com and let's Make It Happen.™