Limiting Your Trials - by Time or by Features?
DZone's Guide to
Limiting Your Trials - by Time or by Features?
Join the DZone community and get the full member experience.
Join For FreeLearn how to build stream processing applications in Java-includes reference application. Brought to you in partnership with Hazelcast.
The sad truth is that nobody buys software solely based on a slick sales pitch. Everybody wants to get their hands on the piece of software first to find out whether they like it or not. And herein lies a pretty complicated problem - you want your users to fall in love with your product. At the same time you somehow want to limit the access to the product so that you can monetize it later.
By and large you have two options here - either hand out a fully functional version of your software for a limited period of time and force users to convert to paid plans after the period passes or you somehow limit the functionality / capacity of the free version available. As most of the software industry tends to go with time-limited trials, so did we. But we soon realized we could do better.
In this post we will describe how we reached the conclusion that time-limited trials might not suit us and what we did to overcome the obstacles.
Until now, when you downloaded Plumbr, you got a 45-day evaluation license, which stopped working when the period passed. Quite soon we noticed that even if we offered everyone to prolong the license for free, the process alone caused us lose some users - the very users who had actively used the product for the whole 45-day period. Those cases fell into two categories.
First, there were people who hadn't found any memory leaks in the trial period. This in itself is nothing to worry about - if you monitor a stable project in a development environment, it can easily happen that you don't stumble upon a memory leak in 1,5 months. It's the production where high volume and frequent releases often cause the problems with memory leaks.
By and large you have two options here - either hand out a fully functional version of your software for a limited period of time and force users to convert to paid plans after the period passes or you somehow limit the functionality / capacity of the free version available. As most of the software industry tends to go with time-limited trials, so did we. But we soon realized we could do better.
In this post we will describe how we reached the conclusion that time-limited trials might not suit us and what we did to overcome the obstacles.
Until now, when you downloaded Plumbr, you got a 45-day evaluation license, which stopped working when the period passed. Quite soon we noticed that even if we offered everyone to prolong the license for free, the process alone caused us lose some users - the very users who had actively used the product for the whole 45-day period. Those cases fell into two categories.
First, there were people who hadn't found any memory leaks in the trial period. This in itself is nothing to worry about - if you monitor a stable project in a development environment, it can easily happen that you don't stumble upon a memory leak in 1,5 months. It's the production where high volume and frequent releases often cause the problems with memory leaks.
Secondly, there were people who had found and solved memory leaks, but
didn't bother to renew the license. I guess our offering was also not the best (prolong the trial for 45 days again and again, until we come up with paid plans) - but even if prolonging the license for free didn't work with them, could we expect them to start paying once we'd announce the prices?
So even if we offered free extension of the license we lost a significant number of users. Simply because the structure of the license was rigid and the offering was not attractive.
When we started thinking about paid plans, we decided to tackle the retention problem as well. We wanted to come up with a model that would not require messing with license keys and other extra activities.
In this point we realized that we can also take advantage of the nature of the product. While it offers a way to avoid memory leaks for many, most of our early adopters are still the unfortunate developers trying their best to put out the fire caused by a memory leak. We saw that many users were highly motivated to use the product to solve a specific problem. Why not try to harness this - we thought - and tie them immediately when we help solve their problem?
These are the key points of Plumbr use that we came up with:
- keep the installation as easy as possible
- offer a long / unlimited license to use the product for hunting leaks
- add a hook to the opening of the leak report - display part of the report, but show the most useful details only to paying customers
- use pricing incentive to encourage people subscribe with a longer term plan, instead of paying for a one-time solution
The hook described above is at the point where the ratio between the cost of using the tool and the alternative cost of using something else (which usually includes involving an external performance expert or someone of your most expensive internal staff) is the highest. Justifying a one time cost of a couple of hundred dollars with the prospect of spending
days or weeks on the consultancy of a performance expert should be quite easy. If we cannot convert the user into a paying customer at that point, then we won't be able to do it at all.
Finally, these are the resulting packages that we'd like to announce:
Pay for every leak report foundFull money back guarantee.Once paid report will always be available in the future. |
Buy a subscription
Opening of leak reports is free during subscription period.
Subscription is renewed automatically every month/year.
|
$250per leak report |
$90per month per server($75 per month when paid for whole year) |
If you are on the pay-per-leak-report "plan", you are displayed a payment screen every time you want to open a new Plumbr report. You can then always start a subscription period, or decide that you still want to open the report with a once-off payment.
Similarly, if you have an active subscription you can always end it and fall back to the pay-per-report plan gracefully - without us sending you a new license file or any other bureaucracy.
We also offer volume discounts and sometimes also site-wide licenses for companies with a bigger number of servers/applications to monitor.
Our long term goal, naturally, is to convert as many customers as possible into subscribers, which is an easily understandable cost for customers and yields stable, predictable cash flow for our company. Achieving that is more a matter of wise product development, excellent customer relations, consistent PR, and a bit of luck.
We believe that we've removed one more hurdle from the way leading us there.
Learn how to build distributed stream processing applications in Java that elastically scale to meet demand- includes reference application. Brought to you in partnership with Hazelcast.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Nikita Salnikov-Tarnovski , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}