Tag Archives: on-premise

How to price new enterprise software products

The enterprise software market is almost always a paid one. So how do you price a brand new enterprise innovation?

sw_px-200pxSoftware is one of those “magical” goods in microeconomic terms: it has virtually no Marginal Cost. So how do you get a customer to pay you thousands—or even millions—of dollars to buy something you can reproduce for free?

If you’re looking for a “magic formula” to calculate the price of your software, you can hit the ‘back’ button. You won’t find that here. Instead, if you are looking for a strategy to establish a tangible, defensible price for an intangible innovation, read on…

STEP 1: Price by the value you create

There are many, many software pricing models. However, at the end of the day, you’re going to have to defend your quoted price. This is easiest to do, if you price based on what your customers value. Figure out what units your customers use to measure value, and then pick a price model based on those units. Now you have Value-based Unit Pricing.

STEP 2: Use ROI to establish your “list price”

Enterprise software purchases are investments in “promised value.” However, it will take a lot of work for your customer to “unlock” that value: they have to get budget approval, initiate a program, execute it without over-runs, integrate it into their business operations, etc. To make it worthwhile, your software will have to provide a large return on this upfront cost—at least 40-50%. If your software cannot do this, it will never clear the triple wicket of business sponsor, IT manager and procurement manager.

Look at the market—and more importantly—what it costs your customers to do the very thing you are trying to automate or improve. Calculate the cost per year and subtract enough for a 40% ROI. Now you have your List Price. (Note: if there is already software you want to displace, price your product to make replacement of it something that yields a 40% ROI. Why should anyone take the risk to buy your product if it is not good enough to do this?)

STEP 3: Use co-development to establish your “maximum discount”

When you go to a new customer with a new product and quote a price, they will immediately ask for a discount (especially if you are new to the market). How do you insulate yourself against this? Establish a fixed lower bound for your software that you can legitimately never price below (at least until 1-2 generations pass and everything changes).

The best way to do this is by using co-development partnerships. Co-development partners not only buy and use your product; they provide added time, people, teamwork and insight to make it better. (This is not only good for them, it is also a path you can use to establish market leadership). Co-development should be rewarded with your Maximum Discount.

Once you have done this, whenever a follow-on customer pushes for a larger discount, you can point out that your co-development partner only received your maximum discount because of the work and time they contributed.

STEP 4: Build your price rate cards

You now have all the tools you need: value-based unit pricing, list price and maximum discount for co-development. You are now ready to give your sales and contracts team all those wonderful spreadsheets to calculate the price of your new enterprise software—at least until the next generation of innovation arrives…

A Few Closing Remarks: Two things to NEVER do when pricing your software

Give it away for free to get the deal*. You will inevitably get enticed to give your software away for free to get a major customer. Don’t fall into this trap. Once you have done this you have established your software truly has zero Marginal Value (not just zero Marginal Cost). It is really hard to negotiate UP from zero. Give away add-ons, charge implementation at cost—do anything—but don’t give away enterprise software for free (*unless you are using a Freemium model, of course).

Demand premium pricing. You may be so proud of your latest and greatest software that you will want charge more than “legacy providers” for your innovation. Unfortunately, unless you can demonstrate—at a visceral level—that your software provides value that no one else can, you have destroyed the ROI value proposition of your product.

Article first published as How to price new enterprise software at Oulixeus

Nine software pricing models evaluated

Pricing software has always been an interesting exercise. The marginal cost to copy and provide software is virtually zero. However, the cost to develop it—and the value of the intellectual property that goes into its creation—is far greater. These two tensions have created a range of models that vendors use to price software. This post evaluates several of these, highlighting ideal (and non-ideal) markets for each.

1. Open Source (or “Software should be free.”) There are many proponents of this – based both on economic philosophy as well as the concept of social production. However, free software does not work – at least for anything that is important to the enterprise. It creates no economic incentives for someone to support you (through documentation, bug fixing, advice, etc.) I do not see this becoming a winning model (unless we fundamentally change our world economy to something from the UFP or Animal Farm).

2. Price per CPU, server, CPU cycle, etc. This model creates interesting incentives: the less scalable your software is, the more CPUs your customers need, the more they pay. As such, it only works in a few places. For utility applications (e.g., web servers, database servers) it is fine, as it encourages vendors to compete to provide the best performing utility. For enterprise applications it is terrible, as it rewards poor performing software.

3. Pricing per unit time. I know—this is from the Main Frame Age. However, it is coming back in some cloud computing circles. Just like pricing per CPU it only makes sense for utility applications. It does not for enterprise applications.

4. Pricing per end user. This model makes sense in the consumer market, as each person who uses the software pays for it. However, it is less suitable in the enterprise market. Many enterprises employ multiple people to work, from different roles, on the same process. As a result, this model requires them to pay more to perform the function they need (ultimately making the software less valuable to them).

5. Pricing based on type of use, i.e., pricing someone who is a service provider different than an end user. I have seen this model used on occasion in the utility space, where I pay more if I using my database to build services I sell to others vs. services I use myself. Whenever, a vendor presents me with this model, I immediately look elsewhere. If you want me to buy and use your product, let me do so. If you want to treat me as a value-added reseller, incentivise me (instead of penalising me).

6. “New car style” pricing. Yes, I made this term up. It is a term I use for software provides who use very complicate pricing (pricing where the sales representative has to use a web portal or spread sheet to figure out my price). This is as bad of an experience as buying a new car (and very hard to scale from sales force perspective). Keep it simple: it will make it easier for your customers to see your value.

7. Pricing based on value created. This is also an interesting model, where the vendor prices based on how much value it provides. Economically, this provides the potentially for the most economic efficiency. However, value can be very hard to measure – especially between two or more parties. Structurally, this looks more like a value chain partnership than a simple sale. However, a software provider occasionally makes this work; when they do, I applaud it.

8. Utility pricing, i.e., pricing based on consumption. This sounds like SaaS (software-as-a-service) but it is not, it is pricing based on unit of consumption. This is ideal in situations where customers can provide a value on each transaction (i.e., it is great for PayPal but terrible for Microsoft Word). It is similar to pricing on value, but prices on the process input (rather than the output) something that can be much clearer to measure.

9. Pricing as a tax. This model is not used much. It is basically pricing unlimited usage of software as a percentage of the enterprise’s revenue, operating budget or some other metric (e.g., headcount, payroll). The big challenge of this is picking the time interval for measurement and billing. However, it can make the value of your software much clearer for C-level decision-making.

You will notice I did not discuss the concept of on-premise vs. SaaS vs. hosting. I did this on purpose. These are delivery mechanisms, not pricing mechanisms. It is important to separate the two, as it allows customers to evaluate your software based on its value (i.e., price) and most effective means of delivery.

Authors Note: I am sure a missed many models. I encourage you to comment; not only on the above, but on items I may have missed. Thank you.