Software Pricing – What message are you sending your customer?

At a recent breakfast meeting, I asked a CEO to explain what he charges for his SaaS based solution. His company is an early stage start-up and is still testing its value proposition and pricing.  Early prospects for the solution have ranged from mid-market size companies up to a few large multinationals with thousands of employees.  The service fees proposed ranged between $20,000 and $150,000 per year.

Without delving into the specifics of the solution, the quantifiable cost justification for the solution relates to reducing recruiting costs. From one point of view, for a small start-up, without a lot of reference customers to substantiate the cost savings, selling a $150,000 per year service is a challenge.  For this reason, I believe many start-ups under-price their product's value and as a result, lose sales.

This theory sounds counter-intuitive, but for a moment consider yourself the CFO of that large company. You likely have between 8% to 15% attrition, so you will need to hire at least 2,000 people annually.  If your average cost per hire for professionals or middle managers is $20K, you will likely conclude that this solution will only affect a handful of the 2000 hires that you need to make. Otherwise why would the software company only be charging $150,000 if you are saving many millions per year? Conversely, if this solution will only affect a handful of new hires, why would you waste your time implementing this solution?

This simple example illustrates one of the problems with software pricing. 

Software, unlike hard goods, does not have raw materials and components that can be rolled-up into a variable cost, which then forms the basis for determining unit pricing. Instead, most software costs are sunk costs accumulated during Development. Also, unlike hard goods, software cannot be touched, felt, or turned on so buyers value it differently from a laptop, TV or an IPod which delivers what they were designed to when turned on.  Therefore, software pricing must be determined by the expected value to be received by each specific client or category of client (based typically on size, industry, number of users, percentage of applications used, etc). As a result, it is very complex to determine the price of software. One rule I have developed over my career is that if a company is not losing a percentage of deals based on price, it is fairly certain that they are not charging enough.

Another lesson learned is that the price of your software and the associated services also sends a strong message about your solution's expected value. Too often, software companies undervalue their product because they don't look that the big picture of what it costs to implement and operate the solution. 

For example, a large company needed to implement a new General Ledger. Typically the GL is sold as part of the financial management suite, which generally includes other products like Payables, Receivables, Budgeting, Asset Management, etc. In this case, however, the company only wanted the GL. The list price of the GL was below a million dollars, yet the company ended up paying five times its list price. In isolation, this does not make sense.

The project to replace the GL was driven by the need clean up a history of 20 years of acquisitions and a current environment that boasted multiple GL systems. The consequence of not doing the project was that the company's ability to do further acquisitions would be hampered.  The new GL would be implemented in dozens of countries around the world and would interface into other existing financial systems, most of which were custom developed legacy systems. The sales process in bidding and winning this deal was incredibly competitive, complex and took over 2 years in duration.  The project was budgeted to take three years and cost over $100M.

I do not believe the winning bidder would have won this deal if they had bid list price. In a $100M project, to bid the software engine at the core of the project for a price of less than $1M would have led to concerns about whether the product was sophisticated enough.  Additionally, the product cost would have also been a fifth of the cost of the major competitor's GL thus leading to questions about whether the two products were comparable. Furthermore, at the list price, money would have been left on the table and given the length and complexity of the sales process, the winner would not have made their expected margins.  So why was the list price so low? In reality, for the rest of their market, it wasn't low because usually GL was sold as a suite versus a standalone application. 

The lesson here is that the list price for this particular deal was wrong. In this case, the software pricing needed to be relative to the other project costs and to the size of pain it is solving.  

A few years ago, I helped a professional services company re-structure their go-to-market and pricing strategy. This company was very successful. Most engagements were gained through referral or repeat engagements with existing customers. They were trying to gain new customers in order to diversify and be less reliant on a few large clients. As they grew, however, existing clients quickly consumed new capacity. The company was being repeating told by their clients that their services were head and shoulders above their competition in quality, reliability and innovativeness.

The company's market was in flux. Traditionally, it had been viewed as automation and control systems, which was more akin to engineering services than software services, but as automation became more software then hardware based, the services provided evolved to more of a software services profile.  Typically engineering services were priced in the $85/hour range while software professional services were $150/hr and up.

To an outsider, their issues were obvious. They were providing premium level services yet competing on price. Their business was so heavily repeat engagement that they could not diversify their client base. At $85 per hour, they didn't have margins to reinvest in sales and marketing channels to develop new customers.  The solution was to immediately raise rates to $105/hr, which they did with great trepidation. The reaction from their customers was mute. They had been undervaluing themselves. More importantly, as they continued to raise rates to compete with IT services companies, they elevated themselves from the engineering services category and were able to expand their customer base.

So is there an easy formula for software pricing? I don't believe so, but here are some rules of thumb that I have formulated from my experience:

• Pricing needs to be viewed as part of the bigger picture of "total cost of ownership" to the customer and value the solution provides. Understand the size of your customer's pain and all the costs required to solve it before you quote your price.
• Understand your competitor's pricing. Set your pricing so you are compared to the companies against which you want to be compared. "Going Cheap" will sometimes drive you out of the competition.
• Pricing is only one term in your "terms and conditions" for doing business. Don't set your price until you understand all of the other terms that the customer wants. Don't hesitate to change your price if other significant terms change. Also, make sure you understand all the terms and conditions of your competitor as they will affect their price.
• 50% of the solution may only be worth 25% of the value proposition to the customer. Software only provides a tool to conduct the business process. If the customer doesn't have the staff or the skill to fully implement or use the software or your software only addresses part of their business process, the value of your solution will be greatly diminished. Consider expanding your offering by adding services or partnering with others. It will drive the cost up but that is okay as long as it drives the value up at a faster rate.
• Match your price to your sales approach and expected time of your sales cycle and vice versa. Just because your price is low, does not mean that the sales cycle will be quick. If the customer decision making process is complex and long, don't bid cheap thinking you can force a quick decision.  Accept the long sales cycle and add more value to your solution and raise your price to create differentiators.

I hope this helps spark some new ideas in how you price what you sell.