Leaky Buckets: 3 UX Flaws Killing Your Product’s Trial Conversion

Raise your hand if you’ve tried to fix a leaky trial in one of the following ways:

• Product tour

• Checklist

• Reminder emails

Now, you can put your hand down because people might be wondering why you’re raising your hand in front of your laptop. You’re not crazy to think that any of the above methods would fix the bucket. They work in small doses and definitely not without the foundations.

Today, we’ll do a few short exercises to help you truly fix the leaky bucket without band-aid fixes.

First, let’s start with some industry data.

How big can a leak get?

Opt-in trials (no credit card) typically convert 8 to 25% of users to paid. 

Opt-out trials, where a card is required upfront, sit around 50 to 75%. 

Freemium is closer to 2 to 5%. 

Those ranges come from Appcues, drawing on a Redpoint survey of free trials.

The data shows that most people leave without paying. From that bucket, the people to focus on are the people who leave before reaching value. 

How do you control whether a user reaches value before churning?

When a user signs up for a trial, they have 2 main goals:

• Try to complete a task they signed up for in the first place

• Attribute the experience quality to your product

When both of these happen easily and in a timely manner, your product experience ensures that a user has reached value before churning. 

If either is missed, the user will never remember your product even if they completed a task on your product. This is why checklists and walkthroughs don’t tell you the true story of a user’s trial experience.

Here’s an example from my work with SafetyCulture

During the trial period, enterprise admins wanted to ensure the right people used the platform to try it before they could decide whether to pay or not. Instead, they would drop off or be handheld through the setup phase by customer success teams. Instead of the trial period being a honeymoon phase of everything being swift and easy, the platform made the user do a lot of admin work. We solved this problem by matching their mental model of managing users. This made the trial experience much more self-serve and way less admin-focused.

So, how does this apply to your product? Try these 4 steps right now.

Step 1: Pick a behaviour that your user will want to try with your product

Your product might have 1 or 5 features or more. But, the user doesn’t care about that. The user wants to do one task using your product’s trial period. They want to assess how easy it was and how much the product helped them complete it. So, pick a task that a user will want to try on your product and nail the UX. Here are 3 questions to help you find that behaviour:

• If a user paid for your product, what’s one single reason they’d pay for?

• If a new user landed on your product today, would they be able to experience that reason?

• What features or elements in your product create noise while the new user tries to experience that one reason?

At SafetyCulture, the behaviour wasn't "learn the permissions". It was "get my team in".

Step 2: Create the right environment instead of adding tooltips and checklists

A trial user is trying to complete one task. You’ve identified the task in step 1. Next, know which steps you can automate or pre-fill so that the user can focus on the steps that they need to. A user wanting to understand how good your product is at reporting shouldn’t need to upload all their data to see reporting working. You can pre-fill the data and show them how well your product tells the story for reporting. 

For example, in SafetyCulture - we knew that a user wanted to quickly invite their team to try the product. So, we gave them 6 preset roles based on user research to invite their team into so that the setup steps were shortened. The user just focused on quickly assigning an email to an existing role. Then, they were set up to trial a multiplayer experience. Without that solution, they had to learn granular permissions before inviting the right people and assigning the right permissions to the invitees. Admin time reduced from weeks to a few quick steps.

Ask yourself now:

• What steps are required to complete the one task that a user wants to try on your product?

• Which steps can your product reduce or take away entirely from that task?

• With the remaining steps, does the user get a real enough experience to test your product?

• What’s the last step in the task that your product can register as completed?

Step 3: Ask after the last step, not after time passed

Imagine you receive an email from a product you tried a few days or weeks ago asking you, “Your trial is ending, ready to pay?”. The problem is not that they’re asking you to pay, it’s more that they’re asking at an irrelevant time. In order for you to remember what the product is and what value you got from trialing the product - you have to remember so many things. You don’t even remember what you were stressing about yesterday.

Instead, attach your Ask from the user after the last step in the trial task. To do this, answer these questions:

• What was the last step in the task?

• How does your Ask relate to the last step and the task overall?

• Does your Ask feel like it’s gating the value or enhancing value? For example, asking someone to pay to view results is gating value. Whereas, asking someone to pay to do more of what they just did is enhancing value. If the user liked how they did a task on your product, they’re more likely to pay to do more.

The last step for you to do is to optimise Time To Value. 

Step 4: How many steps or how much time does the user need to feel the value?

You’ll hear that 14-day trials is enough time for a user to try. That number is either base on assumptions or data that’s collected by testing multiple trial phases. The right trial period depends on your product and target audience. How quickly value is delivered defines the length of the trial. I like to say it’s the Speed of Right. Find the right speed by testing and then optimise. A quick task tracker product can expect a few days trial period. A complex B2B SaaS with multiplayer trial experience and integrations requires longer time. 

Based on research data, you can also model your product’s free trial in a few ways:

• Ask for card details upfront: it increases conversions but reduces sign ups. That might be a good problem to have for your product.

• Reverse the trial: give premium access first. Let the user feel the full value of your product for a limited time and then reduce access once key tasks are completed so that the user knows what they’re missing from real experience.

Here are 2 simple questions to build your first test:

• What’s the average time a user takes to complete the core tasks they signed up for?

• Can you afford to provide more or less value during that period? This is not guess work. If, on average, trial users aren’t completing the core task then there’s no way you can try to add more value. 

This last step is all about optimising. That means you need to test steps 1 to 3 in a few ways before going all in on step 4. Talk to your users > rapidly test assumptions based on user research > optimise what works > repeat. Testing is the fastest way to improve.

This is the same approach I used at SafetyCulture to improve their onboarding churn. In fact, I did the research and testing loop with users and with customer success teams in the business to increase confidence in approach. 

More about how I solved for onboarding churn at SafetyCulture in this case study: https://designbydrops.com/work/sc