It was 7pm Monday night and a Google Now alert went off: it was time to record my expenses. Even though I hadn’t recorded business expenses for long time…I decided that since I’d probably be doing this more in the future: I should switch to a product dedicated to creating expense reports.
Unfortunately, things didn’t turn out as I hoped…
After a bit of Googling, I found what seemed to be the most popular expense reporting software. As I started using the product, my excitement quickly turned into anxiety, then frustration and finally to anger. Getting started with this new product was so frustrating that only after several minutes of trying to use it, I was angry at this new product and finally gave up.
I decided to just use a simple spreadsheet.
After successfully inputting and calculating my expenses with the spreadsheet, I sat back and thought about what had just happened. Why was my initial excitement about a new product so quickly replaced with frustration?
After thinking for a bit, I realized that the onboarding process for the product was inadequate. Naturally, I then thought about how it could be better. I decided to look at this problem through the lense of Jobs-to-be-Done. When I did this, I started asking my self new questions – questions that are not usually associated with designing an onboard process. After some thought, I had an answer for this puzzle:
This product hadn’t taken into consideration of my understanding of the Job and my past experiences using solutions for the Job.
If product designers can design products and onboard processes while keeping in mind the customer’s understanding of a Job and their past experiences using solutions for the Job, designers will drastically increase the amount of people who switch to their product.
So, what was going on that made using this product so difficult?… When I started using the product, I was desperately trying to find some simple, straightforward way to input my expenses – just like I did in the past when I used a spreadsheet. I started clicking on menus and buttons in hopes of uncovering something familiar looking or indicative of Add Expense. The closest things I saw were Upload Receipts and Create Report. Long story short, as I clicked on buttons and ventured down various application windows, I didn’t see anything as simple as a spreadsheet.
I got frustrated. I got angry. I fired the product before I even hired it.
In this scenario, I had low Solution Experience. Solution Experience is how familiar a customer is at using solutions ( products ) to solve a Job. It’s a combination of two things:
- How many solutions the customer has used in the past.
- How proficient they are at using a solution.
In this case, I had a low Solution Experience because I only had used one solution in the past ( spreadsheets ) and I only had used it in a very basic way ( a few text columns and one number column that added numbers ).
The opposite of this would be high Solution Experience. An example of high Solution Experience would be if I had used lots of spreadsheet programs and knew how to use them to calculate and deliver expense reports in all kinds of complicated ways.
Thinking of this as a cartesian plane, one would see this:
The X axis represents level of Solution Experience: the more experienced they are at using solutions, the more they move from left to right.
Here some examples of moving across the Solution Experience axis, using tracking expenses as an example:
A. Tracked expenses, in a very basic way, with one or two solutions: e.g. a spreadsheet or pen & paper.
B. Pretty good & experienced at using one solution ( spreadsheets ) to track expenses.
C. An expert at using one solution ( spreadsheets ) to track expenses in complicated ways.
D. An expert at using many solutions (spreadsheets, various online & offline accounting software, pen & paper ) to track expenses in complicated ways.
As mentioned before, this alone isn’t enough to consider when designing an onboard process: we still need to know how well the customer understands the Job-to-be-Done.
While I was squandering around, trying to figure out this expense reporting software, I had an undercurrent of anxiety: I had little experience with the Job of creating, sharing and using expense reports. This lack of knowledge engendered a lot of lingering questions such as:
What does a correct expense report look like?
Am I missing anything in this report?
What is the client expecting to see?
Will the IRS want to see this…if so what else do I need in here…?
In this case I didn’t know much about expense reports and how to use them, so I had low Job Comprehension – how well someone understands the Job-to-be-Done. The opposite of this, high Job Comprehension, might be an accountant who had formal training in expense reports and has had years of experience creating them.
Using our cartesian plane again, Job Comprehension would be the Y axis. If a customer has very little knowledge about the job and hasn’t done it in many contexts, they are at the bottom of the Y axis. The more experienced they are at solving the Job and the more varied the contexts are in which they’ve solved the Job, the more they move up the Y axis.
Here some examples of moving up the Job Comprehension axis, using tracking expenses as an example:
A. Never tracked expenses before, or only did it once.
B. Had a job where they had to track expenses, but that was only for that one job.
C. Is responsible for tracking lots of different expenses for many different employees at a big company.
D. An expert accountant who has been trained at tracking expenses and has been doing it at several companies over a long period of time.
Combining The Two
When we combine the two variables into one model we get this:
Let’s consider an example of this in the context of using an expense report software:
Q1: I’ve done expense reporting for years, in all types of contexts : I’ve also used many different products over the years and know them all well.
Q2: I’ve done expense reporting for years, in all types of contexts : However, I’ve only used one product the whole time , or, I’ve tried several different products but nothing stuck to me.
Q3: I don’t know much about what an expense report is or how it’s going to be used : I’ve never done this before – I think someone told me to use a spreadsheet.
Q4: I don’t know much about what an expense report is or how it’s going to be used : But I’ve been using one or more solutions for a while and when I do, I usually just use a few features which I know really well.
Designing An Onboard Experience Using Job Comprehension & Solution Experience
Let’s now take this insight and use it to design an onboarding Experience.
The first thing we need, is to learn a little bit about our customer. Since we can’t interview each customer who tries our product, we can ask a few, non intrusive questions when they start the app. So when your customer opens the product for the first time, instead of a flashy video showing off all the great things your product can do, start off with a few simple questions such as:
The first group of questions will tell us about Job Comprehension. The second group of questions will tell us about Solution Experience.
Suppose then, a customer like myself answers these questions and the result lands them in quadrant 3: low Job Comprehension and low Solution Experience.
In this case, the onboarding process needs to be gentle. It may consider starting with explaining why creating expense reports are important and what every expense report should contain. Then, when the UI is revealed, it’s very straight forward and simple. At this point the product should walk the customer through creating a sample expense report with all the necessary pieces mentioned earlier.
After this tutorial, the product could then have a template / wizard approach when creating new expense reports. Each template would be based upon situations which expense report beginners typically face.
A different, example scenario is when someone lands in quadrant 2: high Job Comprehension and low Solution Experience.
In this case, the customer knows a lot about expense reports but probably only knows how to do them with one particular product. Let’s assume that this customer is an accountant who’s only ever used spreadsheets.
The onboarding experience for this customer can skip how and why expense reports are used. Instead, it can start off with explaining how this product works when compared to spreadsheets ( the product this customer knows intimately ). Then they should be presented a UI which won’t seem all that intimidating to them. Of course, your product doesn’t need to have a UI that mimics other products; however, you can show them your version of what they might see first in in their previous solution. In this case, the experienced spreadsheet user is going to want to see where to directly input expenses. So for your product, start them off with a UI that asks them to import or input their expenses.
Improve Your Product Today
To use Jobs-to-be-Done to design an onboarding process for your product today, you’ll need to first consider what stage your product is in: Introduction, Growth or Maturity.
If your product is in the Introduction stage, there’s a good chance you’re still interviewing prospective customers and / or in the process of developing your first version of the product. In this case, you’re able to ask during your Jobs-to-be-Done interviews: how long they’ve been doing the Job and what they’ve used in the past. Consider which quadrant most of these customers fall into and design your UI and onboarding process appropriately.
If your product is in the Growth or Maturity stages, begin reaching out to customers who have recently switched to your product and do another cycle of Jobs-to-be-Done interviews with them. When you have an idea of the quadrants which most of your customers are falling into, think about how your current UI can be broken up to better serve each quadrant. Next, create edited UI designs of your product where some features are toggled on & off depending on which Quadrant the UI will serve. When new customers sign up, include the simple quadrant locator questions in the onboarding process and then serve them appropriate UI.
A Potential Pitfall
From a software complexity point of view, its rarely a good idea to have different UIs for multiple types of users. Even if the code is written with simple feature toggles, multiple UIs can become a maintenance headache.
This is again why its important to interview real customers and ask them about what products they’ve used in the past and what their experiences were like when using these products. You’ll likely find that an overwhelming majority of customers have used the same or similar products. You’ll also likely notice that most customers fall into quadrant 3 or quadrant 2, which means they are either complete novices or improving intermediates.
Also, keep in mind that that as quadrant 3 switchers become long-term customers, they will be migrating to quadrant 2 as your tool becomes their solution of choice. To facilitate this, consider slowly revealing features to them as they use your product or hit particular interaction milestones. For example, if your product is an analytics tool, showing customers how to do cohort analysis on day three won’t be helpful… because they haven’t been using the product long enough to be able to do cohort analysis. Instead, as this analytics product is being used more by a customer, the customer will be approaching a point where they can do cohort analysis in the near future. At this point, the product can introduce cohort analysis and walk the customer through how to do it.
Better Onboarding Means More Switches
When a product designer is able to correctly gauge a customer’s understanding of the Job-to-be-Done and how experienced they are at using solutions which solve the job, they can create great onboarding experiences which obliterate anxieties around switching to your product.
As more customers successfully switch to your product, churn goes down and profits go up.