A question was recently posted in a number of Product Management discussion groups. It read (in part):
…I am working on adding a subscription based pricing model for our product. I have read articles that talk about the “rule of 17” that suggest a monthly payment should be 1/17th of a perpetual license fee.
I have structured the models so that the “crossover” between the License fee model (including maintenance streams) and the subscription model was sometime in the first half of year 2. I have seen 3 year models as well.
What do you use or what have you seen? Have you offered both model for a time and if so what are the conflicts (if any) that arise?
It can sound very tempting to provide a subscription alternative to your own enterprise software, but you need to think beyond simply price, and think through the evaluation model, the sales model, the expense model (you’re now taking on the cost of hosting/operations), and how you go to market, convert leads etc. I’m assuming here that the subscription pricing is for a hosted or SaaS version of you current on premise software?
The approach to take is to start from first principles, and define the value proposition for the end user or customer.
There is a real tendency if you already have an on premise solution to:
- ensure you don’t cannibalize the revenue coming in from that solution
- use the pricing of the existing solution to determine the price of the SaaS version
If you go down either path, the subscription solution is likely to fail.
The first one will always put the existing product ahead of the subscription based product. This is what happened with Siebel on Demand. The existing business had to be protected from encroachment or cannibalization by the on demand business and it hampered the on demand business significantly. Your company will really need to shift it’s thinking to manage this well.
The second is tied to the first, but also ignores a really great opportunity you have to define a true value-based and scalable pricing model that could generate more revenue and have significantly higher customer retention than the current pricing model.
Spend some time with the target customers and understand the value proposition from subscription based pricing, and do some price sensitivity testing with them. This should really help you understand how the pricing can provide value. It may also show that there is no appetite for subscription based pricing, but I’m assuming that is not the situation in your case.
One of the interesting things about subscription pricing is that the money will often come out of OpEx budgets in companies whereas for traditional enterprise pricing, it will come from CapEx budgets. Now a dollar is a dollar, usually, but whose budget it comes out of make s a big difference in how people perceive price.
Additionally the pricing model has to take into account the true value delivered by the software. It is very easy to think of per seat per month or per user per month pricing. It certainly worked for SalesForce.com. But the beauty of subscription pricing is that you are not tied into that model or one model for that matter. But whatever you do, keep it simple! Enterprise pricing is ridiculously over complicated. Use the subscription pricing exercise to address that problem.
Figure out what the key units of value are from a customer perspective and use those for the pricing. There may be multiple models based on user scenario. While you don’t want to force existing customers to move to subscription pricing, you’ll have to figure out a transition pricing model to move them over (and possibly back) if needed.
Think of it this way. If one of your competitors came out with a competitive subscription based offering to your current product, would they simply take your pricing and apply the “rule of 17”? No, they’d figure out a compelling value proposition and pricing model and use that as a weapon against you. Get one up on your competition and do it before they do.
Saeed
P.S. Here’s an article on subscription based pricing that may be helpful.