Time-to-Utility and Jobs to be Done
Why it matters and how software products can reduce their time-to-utility
Hi friends!
Different products and services fulfill different jobs for their customer. For a product or service to be successful, it is almost a given that it must fulfill the job that it is being hired by the customer for.
But one often overlooked metric for any product or service is the time-to-utility (more commonly known as time-to-value) which is the time it takes to fulfill this job (or at least convince the user that it can fulfill this job going forward).
That’s what I’ll be discussing today. I’ll cover:
Overview Of Jobs to be Done
How Time-To-Utility fits in
Tactics to Reduce Time-To-Utility
Jobs to be Done
I’ll first briefly introduce Jobs to be Done (JTBD), a useful framework around product development and marketing put forth by Clayton Christensen. The core idea is that people ultimately buy products and services to get a “job” done. The job is the problem they are trying to solve and is agnostic of the solution and is to get them from their current reality to a better future reality.
For example, the job I want to be entertained when I have a few minutes in between errands may be “solved” by a mobile game or TikTok.
To develop a product/service that fulfills the needs of the customer, a business should first understand deeply what job it is trying to solve for the customer and then aim to fulfill that job better and/or cheaper than others in the market.
Knowing and understanding this deeply is critical to say developing the right products and marketing the products correctly at say Rolex.
Jobs often have functional, social, and emotional components which often can not even be separated.
For example, at the broadest level, many people who buy luxury watches are likely solving the job of signaling taste/wealth than telling time. But some might also be solving the job of wanting to feel more confident or wanting a reminder that they overcame the obstacles of their past when they look at their wrisiswhich are very much emotional jobs.
At a high level, for many software products, the jobs they are solving might be in one (or more) of the following categories (although they can be described much more specifically):
I want to be entertained/have fun
I want to connect with people I know
I want to make more money
I want to save time or money to accomplish something I need to do
I want to be more productive at work
While I could go on about Jobs to be Done, hopefully, you got the gist. I’ll now turn to time-to-utility, but there are some additional links on JTBD below for those curious.
Time-to-Utility
Time-to-utility, often known as time-to-value in certain instances refers to the time it takes a customer to get the utility they were expecting from a product or service.
In the context of the Job to be Done idea we’ve just discussed, time-to-utility can be thought of as:
The time it takes for customers to believe that the product or service they hired to fulfill their job, actually can fulfill their job.
In many cases, the job to be solved is recurring or takes a long time to fulfill, and so time-to-utility can be thought of as the first inkling the customer gets after using the product/service that it will be able to fulfill their job.
In a world of the proliferation of apps and products and where attention is so limited, reducing the time-to-utility is critical for products and services to activate and retain their users and prevent them from churning off either in onboarding or soon after onboarding.
Let’s discuss how.
Reducing Time-To-Utility
While the exact ways to reduce time-to-utility are dependent on the nature of the product/service, let’s discuss tactics that can be used, with a focus on software products and apps.
1. Offer a product-led experience if possible
It goes without saying, but a company that requires you to contact them to learn more about their product will have a much higher time to value and much more friction in their process than one which has a self-serve version of the product.
Companies should push the envelope in terms of thinking about how they might offer a self-serve or more bottoms-up motion that increases trialability and allows prospective customers to try out their product.
When it comes to the typical product which has a self-serve signup model, the ideal approach is having a freemium version of the product which allows users to solve the job they are likely to hire the product for.
Gating all the features which provide the core value behind a paywall will not be successful over time even if apps see a higher free-to-paid conversion initially.
An alternative approach for companies is to offer:
A free trial so users can get up and running immediately. The free trial length should ideally be long enough for the user to see the utility
A reverse trial where users are up and running immediately on the paid version, and then are downgraded to the free version if they don’t pay at the end of the trial period. This especially works well for products where some of the highest utility features have to be kept on the paywall for various reasons (cost, etc).
2. Have a great onboarding experience
No matter the type of product, it is critical to have a great onboarding flow. The ideal one is as simple and frictionless as possible but can learn the key information to get the user signed up and tailor the product experience for the user.
A great example is TikTok, which gets some basic information, and then drops the user into the product.
It’s worth thinking about the onboarding flow through the lens of “how can we help the user get the utility in the lowest amount of time”
Some tips around onboarding are:
Elimination: Eliminate (or delay to post-onboarding) any steps which don’t help get the information needed to help the user see utility for the first time or sign them up.
Ease: Order steps from easier to more difficult when possible and minimize the information that needs to be asked from the user. Also, use autocomplete and use typeaheads for pieces of information where possible.
Drop users in: Once you get the bare information you need, try to drop users into your product and make it such that they can take the core actions to see utility from it as easily as possible
Doing > Showing > Telling: When users are dropped into the product, ideally help them do the things they’re likely to need to do to see utility (interactive tutorials), after showing them (graphics). These are often better than telling them (text-based instructions).
Mario from Wagr wrote a great piece on how Wagr re-did their onboarding to minimize the time-to-fun (where fun can be thought of as the utility their app offers). As you can see below, Wagr, which is a social betting app, tries to help the user place a bet within 20 seconds, as opposed to going through the onerous KYC requirements (which happen later in the process).
Similarly, TikTok does a great job of dropping users into the FYP page based on some basic information, and then tells you it will get better over time. They keep the onboarding focused on critical information needed to tailor the experience and then drop you into the real experience quickly.
3. Templates
Often, users don’t even know how to get started with a product even though they have some idea of the job they’re trying to accomplish.
Narrowing a product’s surface area is a great way to help focus the user to see some of that initial utility, and a great way of doing this is through templates or other opinionated ways to focus the surface area.
Templates can be either incorporated as one of the final steps of onboarding or users can be dropped into the product with some templates visible.
As an example, Canva does a great job in its onboarding of asking the user what they want to create at that moment and starting them off with a template to do so. This takes the user halfway there and reduces the time-to-utility.
4. Observe in the Background
It can be difficult to get users to change their behavior or existing workflows or use new apps/surfaces. But one approach that many products can take is silently inserting themselves into existing behaviors and observing all of that and using that to either learn about the experience or change it in that experience.
For example:
Grammarly has an editor users can type text into to get spell-check and grammar suggestions. But it’s Chrome extension which can do so in Google Docs, Email, etc can provide the initial value much quicker because it just is silent in the background until a user is editing a piece of text in their existing workflow. In general, chrome extensions are a good way to do this.
In some cases, products take time to learn about your behavior and workflows before they can be useful. In those cases, silently observing and learning in the background and then suggesting things can be a good way to learn without necessarily being top of mind for the user (and so lowering their perceived time-to-utility).
For example:
Magical, a text expander app, observes your behavior and recommends shortcuts and automation when it sees you doing things over and over. This allows you to set up an automation for something you know you’re doing frequently quite quickly.
5. Approximate the Real Experience
In some cases, a self-serve or product-led motion doesn't work. There might be too many stakeholders involved, a complex set-up needed integrations with the warehouse or some IT setup, etc.
However, even in these cases, products can do better than a “request a demo” or chat with the sales form.
Some possible solutions are:
Demos: Have a good, ideally interactive demo of the product that users can see, ideally without contacting anyone. Ideally, asking the users a few questions and personalizing the demo can be helpful to help them envision whether this product can help solve the job for them.
Sandbox instances: Having an example instance of the working product that users can play around with (with all the data already pre-filled / connected) can help users see what the product does and how it could solve their problem. Again, personalization if possible works well. For example, many API companies let you try running the API or at least have great docs so users can see how they work. Similarly, companies that require say IT setup or data warehouse credentials can have a sandbox instance running on fake but sensible data to give users a feel of what it might look like.
Additional Reading
Jobs to be Done Theory in HBR
Competing Against Luck by Clayton Christensen – book which details jobs to be done theory
TikTok User Onboarding Overview by AppCues
Time-to-fun by Jon Lai
Wagr Product Onboarding to reduce time-to-fun by Mario Malavé