I’ve been in the software industry for much longer than I’d care to admit at this point. That’s another blog post though. Much of it has been centered around building products. One of the things that seems to not go away is the expectation that a software trial is infinite, or free. Regardless to whether you pay a single penny, trials aren’t free. They cost companies money - even if you’re evaluating it on your own computer. The moment you move from evaluation to development, you’re hurting the company that builds the software. Here’s how…
First, I’ll be discussing software trials at a high level. While all trials have very similar ground rules, you should always read the software providers end user license agreement (EULA) to be sure of what you can and can’t do. However, it would likely be easier just to send them an email or place a quick phone call.
Imagine walking into a car dealership to buy a car. You like it. The website looks great, and it probably has very good reviews. While you’re there looking at the car, you continue to feel good about your probable purchase. However, you need to be sure that it really does work the way you think it will. You need a test drive to “feel” if you like it in addition to making sure it has all of the basic features you’re looking for. This is the equivalent of your software trial. You try it out and if it meets your needs, you buy it.
Now imagine walking into the same dealership and after the test drive, you ask to keep that same beautiful car in your driveway. You tell the salesman that you don’t know for how long. You just want to be sure that it really is the car that you want. You ensure him that you wouldn’t be asking unless you were pretty much sure you’ll be buying it anyway. Please try this. I think you and I both know that the dealer will almost immediately laugh in your face (even if only on the inside).
While the previous example can be considered a bit outrageous, it’s only because we all collectively know better, but this is exactly the equivalent of what developers do with software trials, and it’s wrong. Just because you can’t physically touch a product doesn’t mean that is should be treated any differently.
Before I go any further, let me assure you – I get it! I came up in technology when it wasn’t cool to pay for software. In fact, paying for software was almost an insult. Though, the more involved I got with building software products, the more I realized that I was only cheating the companies that were working so hard to provide the value packaged up with all those bits of 1’s and 0’s.
Why Have a Software Trial Anyway?
Software trials are not a necessary evil. They’re absolutely required. Software comes in so many forms, with so many teams of varying skills and approaches, that you MUST try it out before you buy it. The rare exception would be highly established, large companies like Microsoft or Adobe. If you’re not offering your target customers a trial, you literally have no idea how much money you’re leaving on the table.
Software is Infinite, Right?
All too common, the average person – especially developers – have no empathy for a software trial or software in general. After all, it’s clearly an easily duplicated commodity. In most cases, generating another product for the next customer doesn’t even require someone clicking a link, much less writing a line of code. So a trial doesn’t cost anyone anything, right? You couldn’t be more wrong. Every trial represents a prospective customer and it also represents huge amounts of opportunity cost. A trial period is the equivalent of inventory on the shelf.
Evaluation vs. Development
Unless we’re talking purely about a development platform (e.g., Appcelerator, Xamarin, Windows Azure, or Twilio), there’s nary a software trial out there that is meant for development. In fact, most trials have End User License Agreements (EULA) that expressly prohibit development. Evaluation isn’t development. Evaluation is the act of comparing your requirements list to the product’s capabilities with the intent of making sure that the software product meets your needs. The moment you begin writing code, you’ve probably crossed a line.
Development vs. Development
Whoa… Is that a typo? Nope. As you already know, many words are ambiguous regardless to their literal meaning.
Developing for yourself or a client is worlds apart different from developing for the sake of determining if something works. For example, a trial generally allows you to evaluate if an API works. Trials DO NOT allow you to begin developing against requirements or build a proof of concept (POC). This kind of evaluation constitutes use of the software, not evaluation. Like with any other product in any store, using the product requires paying for it.
Try eating a banana in a grocery store without paying for it and then explain to the manager that you were only evaluating before deciding whether to purchase a bundle of bananas. I think we both know this won’t work out well for you. Like with the API of software, the banana itself is part of the value proposition – which you should pay for.
Why is this Wrong?
More than likely, you may be thinking that this is not really a big deal. You’re right. This isn’t a big deal for the developer. It is a big deal for the software company though.
Most software companies primarily make money on the sales of their software, or licenses to use their software for specific periods of time. That money isn’t going to Scrooge McDuck’s mansion filled with gold bricks. Most of it goes right back in to the software development process to pay product owners, designers, user experience experts, developers, testers, and more. That money will go to better the software that you clearly are growing to love.
Regardless to whether this software is hosted or not, the moment you begin evaluating the software, you begin to use their resources. The best case scenario is that you only contact them once, but that one question may go through 3 or more employees. The answer to that one question may have cost some companies up to several hundred dollars. If you’re indeed only evaluating, that’s okay. The company assumes a certain amount of risk and cost associated with converting a prospective customer into a real customer. If you’re developing, this is not the case, and you’re wrong.
An evaluation question is something like, “How do I configure feature X?” If you’re a developer, that question might be more like, “How do we integrate our system Y against your feature Z?”
In contrast, a development question will most certainly involve code, and it might sound a lot like, “Here’s our use case. We want to integrate system A and B with your API using end point C, but we’re running into this error.” Or the question might be a but more more general in asking about the specific end point. Speaking of points… you should get the point now.
Let’s also not forget what happens when you begin a trial… the company begins tracking this. It’s not for nefarious sales-mongering purposes either – well, that’s part of it – but your trial is an indicator of interest in the product. Overall interest in the product can translate to sales. Sales translates to revenue. Revenue translates to investment and planning that will result in the production of more version of the software you’re evaluating and support services that you’ll be using when you are paying customer.
What you do during your evaluation DIRECTLY impacts the entire company that builds the software.
Why this Post?
If you’ve made it this far, you already know why – and you’re like either an offender, or directly involved in offering software trials yourself in some way. Regardless to who you are, please know that software is built by people just like you. You’d get pretty upset if those people missed a meeting with you, just like they’ll likely be a bit frustrated if you miss an evaluating deadline or began using their resources without paying for them.
In short, when buying software, let’s be a good citizen. When you do, it helps us all help each other. In the end, you’ll be using better software, faster.
This article is cross-posted from my personal blog.