Increasing SaaS Feature Adoption with Jobs-to-be-Done
As Jobs-to-be-Done continues to gain popularity in the SaaS community, many founders and product teams are struggling with the same question:
“How do we apply JTBD when there is no purchase?”
A conversation that I have on a weekly basis goes something like:
“My team at Slack is in charge of video and voice chat. We launched the feature and it’s going well but some users have tried it and keep using it, and some users have tried it once then stopped. We’re working to improve the feature and grow adoption, but we want to make sure we continue to please our loyal users, while also converting more trial users to adopters. How can we figure out why people are switching to the feature so we can understand how to improve it based on the jobs that it’s hired to do?”
We tend to use large consumer purchases like buying a car to teach jobs-to-be-done, so feeling uneasy about applying it to the adoption of a new feature is natural if you haven’t done it before.
The conversation with the Slack team is fictional, but the anxiety is real. I’ll use the new Slack feature as an example to lay out three steps that you can take to ease your anxiety and get ready to push forward with your project.
Just to be clear, we’re not out of bounds when we apply JTBD this way. Jobs-to-be-Done is a framework for unpacking a decision. Adopting a new feature is a decision, so we’re safe.
Over the past year I’ve been fortunate to have conducted a lot of feature-focused projects with teams in SaaS and social media organizations. I’ve found three adjustments that we need to make in order to successfully unpack adoption-focused jobs:
- We need to be clear about what we’re trying to improve. When the project is purchase-focused, the goal is usually focused on a financial metric (increase sales, increase subscriptions, increase repeat-purchases). In this case we’ll be focusing on a metric that relates to the adoption of our feature.
- We use a different process to pick who we want to interview. When we study switching around a purchase, we interview people who have made the purchase. Since we don’t have that event as a recruiting criteria, we’ll adjust our selection process to focus on the creation of a new habit (using our feature as their new solution).
- We conduct our interviews differently (kind of). When we interview, instead of starting with the purchase and unpacking the story that led up to it, we’ll detail how one feature faded away, and the new feature took it’s place as the “default solution” in the user’s mind.
Setting Up Our Project: What are we trying to improve?
Your team probably has a good understanding of the success metrics for the feature. Setting the goal of the project is an exercise in converting the metrics to jobs-to-be-done language.
In jobs-to-be-done terms, we think of adoption as the user’s decision to hire the feature the majority of the time (it’s their default solution).
In the user’s words: In the past, when it came time to do a video call I would usually use Google Hangouts. Now, when I need to make a video call, I almost always use Slack.
As we interview, our goal will be to detail the story as they progress from the the old way, through trial, to adoption. Buried in the user’s story of adoption are the details that we need to improve the way we craft and position our product.
A project goal for Slack voice and video would look like: We are focused on understanding situations that users are in that cause them to consider Slack voice and video as a solution, try it, and then adopt it as their new solution. Arming ourselves with the details of these situations will provide us with the knowledge that we need to make product and messaging decisions to attract more users like the successful ones that we interviewed.
Picking The Right Users to Interview
If our team’s focus is to improve the metrics for our feature (time spent using it, number of daily active users), then Jobs-to-be-Done prescribes that we talk to the innovators (users) who have adopted it as their new solution. Doing so will arm us with the details of the situation that they were in when they decided to try something new (the struggle), and the details of how they decided to fully adopt the new solution (hiring this new feature to do the job on a continuing basis).
When we’re conducting a project focused on increasing the sale of our product, the process of selecting people to interview starts with a list of people who have purchased the product recently. Then we add criteria to narrow our sample based on the question we’re trying to answer.
Establishing our Adoption Threshold
Since we have no purchase in this case, we’ll use an Adoption Threshold that the team agrees upon as a selection criteria.
If our Slack team agrees that Video Calls per Week (VCW) is the metric that they’re working to improve, and one that is currently collected (we have access to the user data), we can consider using it as a metric for adoption.
To establish our threshold for adoption, we’ll leverage the data that we have about user behavior, and the instincts of our team members.
We lean on the team’s experience because typically the statistics don’t tell us the whole story. Someone on the team will say: Within the top 20th percentile there are a lot of salespeople who do daily webinars with customers and they skew the data because they do 10 VCW. If we want to get a sample of more than just salespeople, we should lower our threshold and consider adoption somewhere around 4 or 5 VCW.
Usually the process of establishing this threshold happens over a few meetings with the team and a few trips to the database to test our theories, but it shouldn’t take more than a day or two to nail down.
Identifying Recent Switchers
Now that we have our Adoption Threshold (>= 4 VCW), we need to identify users who have switched recently so they can easily recall all of the details of their story. We’ll do that by looking for a pronounced change in usage over a short period of time.
Our recent switcher criteria would looks something like: No more than one VCW per week in the weeks leading up to a 4 VCW week, followed by sustained 4 VCW usage.
In our database, these users might have usage metrics that look something like this:
Our goal is to examine our user data and find users that have exhibited that pattern of usage, then generate a list of uses that we can contact and ultimately decide if we want to interview them (are they willing to talk to us, and do they meet the rest of our selection criteria).
When deciding if you have a long enough list of users to reach out to, ask yourself a few questions:
- Will most of our users be open to talking to us? This depends on factors like the industry your business is in, your company’s history, how often you reach out to users for feedback (are they tired of your weekly survey emails?).
- Will the rest of our selection criteria filter out a lot of the users that we initially reach out to? For example, if one of our questions asks if they were the decision-maker when it came to using the new feature, and we don’t have data that will give us the answer (we have to ask them instead of leveraging our CRM/user data), we might end up reaching out to a lot of users who ultimately aren’t good matches for our interviews.
If our data pull doesn’t produce enough users, it’s time to have another team discussion and talk about loosening our criteria (is the step-change that we’re looking for too demanding, or is our VCW Adoption Threshold too high?).
If we think we have a long enough list of users to reach out to, we can move on to adding additional criteria to make sure we’re talking to the right people.
The most important of these criteria will be centered around making sure that they were the primary decision maker. To make sure we talk to people who have control over which platform they use, we’ll survey the list of users that our database generated and ask this question:
Think about the video calls that you’ve participated in over the past four weeks. Which statement accurately describes these calls:
- I picked the platform for the calls in most instances.
- Someone else picked the platform for the calls in most instances.
- It was a pretty even split. I picked the platform for about half of the calls, and someone else picked the platform for the other half.
When we’re ready to send our survey, we should be comfortable that we’re reaching out to users who adopted our solution recently, did so of their own accord, and did so in a fairly concentrated period of time.
Focus the Interview on the Right Time Period
If you’ve done jobs-to-be-done interviews, you’re used to kicking the interview off in a familiar way: “So you bought a new car recently? Which car did you buy? When did you buy it?”
We teach Jobs-to-be-Done using considered purchases like cars because of the amount of mental decision-making energy that is concentrated into a small amount of time. For these kinds of decisions the risk is high (financially), and the moment of decision is easily identified as the instant that the financial transaction is executed. That instant is a great starting point for our interview because people can remember it in great detail and we can anchor our timeline off of it.
Once we have that anchor as our moment of purchase, we can ask about their last car as a way to bracket the story and fill in the story between those two points. The idea of bracketing the story is critical to making sure we don’t spend 60 minutes of the user’s time and our time talking about the wrong things (I’ve written more about how important this is here).
Now buckle up. You’re about to learn a new way to bracket the story and take your interviewing skills to the next level!
If we’re talking to a user about how they adopted the new voice and video feature in Slack, we still need to work to bracket the story, but we’ll need to take a couple of extra steps to do so.
When we kick off our Slack interview, we’ll do so by developing an understanding of how much they currently use the feature.
Start with some questions around how they currently use it and when they started using it:
- So in the survey we sent out you said that you’ve been using the feature. If you think back over the last few days/weeks, how many times have you used it?
- And how many video calls did you do total over the past few weeks?
- When you weren’t using Slack for your video calls, what did you use?
In our heads we’re trying to figure out:
- Did they add Slack to their voice-and-video solution mix? For example, they’re still using Google Hangouts and Skype, but now also using Slack on occasion as part of the mix?
- Did they completely replace their previous solution or part of their previous solution with Slack? For example, they used to use Google Hangouts and Skype, but they’ve completely replaced one of those with Slack.
Once we’ve formulated an understanding of their current level of adoption, we can start working up the timeline to understand the nature of adoption, and what caused them to switch.
If we were interviewing someone about their car purchase, our next step would be to ask them about their last car. This would be an easy leap to the top of the timeline that would lead us to the first thought. “Sounds like that car worked for you for a long time. When did you have the first thought that you might need something new?”
In most situations, the user who tries a new feature isn’t thinking explicitly about replacing their old solution, so we don’t have the luxury of the “previous solution” that the car interview affords us.
Luckily there’s an easy fix for this. Instead of taking one big leap back in time, we’ll take two smaller steps:
- The first will focus on the first time they tried Slack voice and video.
- The next will be focused on understanding what they used before Slack V&V, and will take us to the top of the timeline around the first thought.
Now that we have an understanding of the period in time that we want to examine, all of the standard jobs-to-be-done interview techniques apply. We focus on probing into their story to learn:
- What did they like about their old solution(s) and where did they struggle?
- How did they first hear about the new feature? How did they make the decision to try it?
Remember, we’re looking for causality: What situation caused them to take the time to try our new feature and then fully adopt it?
It’s Time To Try It
If you can work through these three steps, you’re ready to schedule some interviews, uncover the jobs-based insights, and improve the adoption of your new feature.
Take comfort in the fact that the first few interviews will feel a little sloppy. They feel that way for everybody. Especially as you get a feeling for how much time you need to spend on each portion of the interview. After the second or third interview you’ll hit your stride.
If you have questions about your specific project, send us a note through the Re-Wired website. If you have a question/comment about the method I’ve outlined leave a comment below.
You can also:
4 Comments
COMMENTS