Reasonable Trial Durations: 30/30/30

I’ve come up with a way for trial software to be fair and recover lost sales opportunities. The secret: 30/30/30.

30/30/30While doing Java development, I was looking for a new IDE for Windows. Naturally, my hunt ended with IntelliJ, with Eclipse and NetBeans close on its heels.

What started the whole chain of thought for me, though, was IntelliJ’s trial period. Frankly, I really respect a company that has enough faith in their products that they let you use them, unencumbered, for a month in order to make an informed purchasing decision.

Oddly enough, though, it wasn’t enough. Allow me to explain.

The purpose behind a trial period is to allow end users to “log enough flight time” with the product that they know whether or not it meets their needs.

And here’s the problem. I have an existing code base of inter-related projects that I need to import into the IDE. And, since this is for work, my schedule is fairly swamped. I can only come up for air to do an evaluation once every week or two just for an hour or so.

What inevitably happens is this: I install the software, validate it installs, then a week or so later, I try to import; it fails, so I table the project until I have more time. A week or two goes by, and I try again, getting closer. Then, when I come up for air and try to get a bit further, the evaluation period is over. I’ve realistically had about less than three hours using the software, and none of it in the IDE writing code.

This happened to me last year as well.

And, what’s the natural conclusion at this point? I don’t know if it will meet my needs or not. Thus, a purchase doesn’t happen.

From marketing’s perspective, they think that the following scenario is the norm: a user downloads the project, tries creating a project, slings a bit of code, gets married to the IDE, and is willing to pay to keep the experience. In fact, I’ve done just this, and I really love IntelliJ.

But, no matter how much love I have for the product, if I can’t move our corporate applications into it from an existing source base, I can’t justify the site-wide purchase. End of story.

Oh sure, I could talk with the kind folks at JetBrains and ask for an extension, and I’m sure they’d give me one.

But that isn’t the point.

Being a software provider myself, I see this as a generic problem. What if I want to produce trial software that’s fair. I can’t have my customers not being able to make a well informed decision for running out of time.

Here’s my solution… 30 days, 30 invocations, 30 hours – Whichever Comes Last

Here’s how it works:

  • You’re guaranteed at least a month of physical time.
  • You’re guaranteed at least 30 invocations.
  • You’re guaranteed at least 30 hours.
  • When all three of the above goals are hit, stop the trial.

Implementing this isn’t be hard at all. It’s also quite fair and balanced.

If you are doing real work, making use of the application for 30 days, then you’re going to quickly chew through the 30 invocations and 30 hours.

If you have just haven’t even tried the software enough, you get 30 attempts.

Finally, the 30 hour rule recognizes if you haven’t had time to actually experience the software.

I’d like to see vendors start taking this approach. It’s a good one, too. It would certainly result in more sales.