You strategically placed your bets on the best acquisition channels. You formed the absolute best campaigns. The free trials come rolling in. There's excitement.
It's working. This will help us meet our goals.
And then 30 days go by and 💥. You're hit with a harsh reality: 90% of your free trials churned.
Right out of your funnel.
Every cancellation hurts. When you see the cancellations come through your Slack notifications, and it feels like someone ran up to your baby, punched it in the face, and ran away.
So what do you do? You've gotta do some free trial troubleshooting.
In this 2-part post, you're going to learn exactly to:
Use the JTBD framework to conduct interviews
Leverage in-app experience tools to understand the aha moments
Conduct an onboarding teardown and reconstructed the best path forward
Plus, I'll cover some of the other contributing factors leading up to growth!
Meet Rindle: Project management of the future
For the purpose of this post, I'll be covering the work I've done for one of my favorite clients—Rindle.
Rindle is a project management tool for growing companies—except they've got a twist.
Rindle comes with a little thing called "workflow automations" which helps you create rules around your boards, tasks, and subtasks to automate the project management process.
If you have any experience with “if, then” statements and conditionals, you can definitely take advantage of the power of Rindle.
In April 2018, Rindle had a goal: Get new free trial users by the end of the month. Even better if most of them become paying customers.
Here's the mix of what we did:
Outbound sales emails to founders and project managers in up-and-coming agencies
Promoting a webinar through Facebook ads
Promoting the product through services like Capterra
The beginnings of a content marketing strategy for Rindle's blog
Needless to say, we blew the goal out of the water.
Except we had one glaring problem—the free trials weren't converting like we had originally planned.
This is where I reveal the secret to the sauce.
It's the step most organizations don't take which ends up costing them time, money, and effort.
Leveraging JTBD framework for interviews
The JTBD Framework is a research process designed to get to the root of a customer’s motives and intentions. It's not sexy, but it's what works.
“A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her,” according to Alan Klement, JTBD practitioner and expert.
Within the context of SaaS, when you gain a user, they've essentially hired your platform for a "job"—hence the "job to be done".
Typically that “job” is a new, better version of the customer and the way they see themselves.
You can also use it to troubleshoot the onboarding process.
But we can't just bug our customers, free trial users, and cancellations willy-nilly.
Moreover, it's a huge challenge to get unfettered, real feedback from people about why they left or won't pay.
"What's wrong with our onboarding?" is also just a little tactless, and surprisingly enough, few people will rip your product apart (most people are actually really nice, even if you beg for it).
That's where JTBD comes in
It’s a set of questions designed to understand the desire for the product, the problems they're hiring Rindle for, and their experience with the product.
For the questions, I drew inspiration from a few other JTBD practitioners and modified the questions to better suit our needs.
We didn't exactly have a ton of customers to start with—but to be honest, even if you do at least 7 interviews, you're still likely to find some patterns and outliers between all of the conversations you have.
We knew it would be tough to engage someone who's already cancelled, so to start, we implemented a one-question feedback form that shows up after someone cancels.
The question is simple: "What led you to cancel today?" with an open-ended text box.
When someone cancels and fills out this text box, the response is automatically populated as a card in Rindle and uploaded to the "Customers" board under the "Cancellation Reasons" list.
We can do what we want with the data from here—like populating it into a spreadsheet for future use. (And actually, in the future, we plan to move towards a radial selection with a set of reasons based on the feedback we got. We expect this to increase the likelihood of someone giving us a cancellation reason.)
Next, we created a short list of customers and free trial users to interview.
We had about 6 customers—all in different stages of their journey with Rindle—and we managed to get 1 cancellation user on the phone for an interview.
The interviews were 30 minutes long and we followed the same template every time:
How would you describe your role?
What are some of the projects you have going on right now?
Tell me about your workflow as it relates to Rindle.
How did you go about looking for it?
Do you remember talking with anyone else about the decision? Who? What did they say?
Did you look at other solutions? If so, why did you pick this one over something else?
Did you use any other solutions before this one? Dig deep into each one: what worked well, what didn't, why they tried something else, why they switched again
Before you made the purchase, how did you imagine life would be better with Rindle?
Why did you finally stick with this one?
So now, what's working well about Rindle?
What isn't working well about Rindle? What gives you the most anxiety and stress?
Lastly (and this is kind of a segue), do you read content related to work? What topics do you typically read about?
After scheduling and conducting a few interviews, we noticed a few themes kept popping up over and over again:
Most people loved Rindle and its scalability for growing teams at no cost, but they all felt like they weren't using it to its fullest potential
Workflow automations are the game-changer here, but we acknowledged not doing the best job of highlighting them after someone's fully onboarded
Ease of use was hands-down what everyone loved about the platform, but we realized we needed to dig deeper into what this means
"Ease" means something different for everyone.
Dashboards were both confusing and powerful—most people knew how to use them, but the display was challenging for people to navigate
We weren't making it easy to invite other team members
There were a few critical bugs we needed to fix
But the absolute most mission-critical interview we did?
The one guy we interviewed who cancelled.
I mentioned before that it's pretty tough to get cancellations on the phone unless you offer some kind of incentive or promise you're not going to try to sell them back into the platform.
For this interview, I pitched something a little different:
I'm not a Rindle employee, but a third-party service provider.
The interview would be between me and the interviewee; no one from Rindle would be present.
And in return, I got some pretty crucial, no-holds-barred feedback:
The onboarding really turned off the user. When digging deeper into what this meant, we uncovered that there were buggy issues that he kept running into (things we've since fixed). Rindle has a few pop-up videos when navigating to different parts of the platform, but since there isn't really a sequential flow between every experience, they seemed almost out of place and perhaps too complicated.
The very first landing zone when logging in for the first time is the Dashboards page and we weren’t doing the best job of showing our users the value of this feature.
The in-app videos made Rindle seem more complicated than it actually is—as opposed to maybe floating suggestions that can be turned off at any time.
Well I say bingo!
We were definitely onto something…
Up next: the aha moments and the onboarding teardown
Customer research for both free trial users and customers (and even cancellations) was just the beginning of our onboarding journey.
Leveraging the JTBD framework for interviews not only helped us connect with our customers, but also helped us guide our onboarding teardown.
Instead of hacking away at a teardown without understanding the context first, we decided to start with the source first—and through interviews, understand exactly what our customers were struggling with.
In Part 2 of this series, I’m going to go step-by-step on how we: