How to run a software trial that tells you something

A software trial tells you something only when it tests the work you actually do, with files you actually use, against criteria you wrote down before you started. Set a fixed end date of one to two weeks, test the parts that cause trouble later, such as import, export and sharing, and decide before the trial ends. The video above shows the sequence in about 80 seconds; this page gives the reasons and the limits.

A ranking can narrow the field. The project management software ranking and the cloud storage ranking show which products are worth a trial, and how we rank explains how those scores are set. A ranking cannot tell you whether a product fits your team, your files and your habits. The trial is where that gets checked.

Write the success criteria first

Before you sign up, write two or three sentences that describe what must be possible at the end of the trial. Make them concrete enough that a colleague could check them. For a project tool, an example is: "Move last quarter's plan into a new project in one afternoon, assign tasks to five people, and export the task list." For cloud storage, an example is: "Share a folder with a client who has no account, open the file from a laptop with no network, and find a contract from two years ago by searching its text."

Write these before the first login, because a trial quietly redefines success once you start using it. After a few days a tool's layout and defaults feel normal, and a missing feature can seem unimportant. A written list stops that drift.

Use your own task and your own files

Demo data is built to show a product at its best. The sample project has tidy dates, the sample folder holds a few small files, and the sample workspace has none of the clutter a real one collects. None of that resembles your work.

Use a task you already do: a project that is due, a folder you already keep, with the names, nested folders and file sizes you already have. Match the volume too. If your real folder holds thousands of files, load thousands, not a dozen. If the files are sensitive, use copies, and read the vendor's data terms before you upload anything.

Test the edges that decide the long run

The first hour with any product looks similar to the first hour with the next one. The edges are what you live with later, so test them on purpose:

• Import. Bring in a real export from the tool you use now. Count what arrived: attachments, comments, dates, owners and folders.
• Export. Ask for a full export and open it outside the app. A comma-separated file is a useful test. RFC 4180 describes the format most CSV implementations follow: a field containing a comma, a double quote or a line break should be enclosed in double quotes, and a double quote inside such a field is written twice. The RFC also notes that some programs, Microsoft Excel among them, do not use quotes at all, so include a field with a comma and a line break and check what comes back. The lock-in and exit costs lesson explains why this test matters most.
• Offline and mobile. Turn the network off, edit a file or task, then reconnect. Check that the change arrives once, with no duplicate and no lost edit.
• Sharing. Share with an account that is not yours, at each permission level you plan to use, and check what the other person actually sees.
• Search. Search for a word that appears only deep inside a document or an old comment, not in its title.
• Speed and support. Time the action you repeat most often, at your real volume. Send one real question to support on the second day and note how long a useful answer takes.

Keep a friction log and a fixed end date

Set the end date on the first day, one to two weeks away, and put it in a calendar with a reminder the day before. Treat the length as advice, not a rule. One person with a simple task may need less time, and a switch for a whole team may need more. The point is the deadline: a trial with no end date drifts into use without anyone deciding anything.

Keep the log in a plain text file. Write one line per friction: the date, the task, what got in the way and roughly how long it cost. For example, "Tuesday, attaching a file to a task took four clicks and a page reload." A log is what lets you compare two products at the end, because memory of a bad afternoon fades quickly and makes every tool seem fine.

Check billing before the first day

Before you enter payment details, answer three questions from the pricing page and the sign-up flow, and write the answers in the log:

1. Is a card required to start?
2. Does the trial convert to a paid plan automatically, and on which day?
3. Where is cancellation, and does it take effect at once or at the end of the billing period?

A trial can be free for its first week and then charge you if nobody cancels. How we rank describes prices as models and limits rather than exact figures on purpose, so the vendor's own page is the final word on cost. The subscription or one-time purchase lesson explains how the payment models differ.

Run two finalists on the same task

Trials are easier to judge in pairs. Choose two finalists rather than five, give both the same task on the same days, and use the same criteria for each. How to compare products fairly covers how to set that comparison up. The comparisons index lists pairs already set side by side, and all categories shows every ranked list if you want to find a second finalist from another angle.

At the end, score each finalist against the criteria you wrote on the first day, using the friction log for the details. Decide by the criteria, not by which product was more pleasant to open. Then cancel the other one the same day. An account left open is a small decision made by default, and it is easy to forget the card you added.

A trial does not prove that a product will last. It shows whether the product fits your work for the next few weeks. The export test shows whether you can leave it later.

Sources

• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, Y. Shafranovich, 2005. An informational document that describes the CSV format most implementations follow.