Integrating Jobs to be Done in your User Research

The first time I used the Jobs to be Done framework I'll admit I went into it with a bit of a “fake it til you make it” approach. I read a few blogs and watched a couple of YouTube videos, including a hugely insightful one by Tony Ulwick. Thankfully my somewhat empirical approach yielded some great learnings that I’ve since been able to improve and build upon for future uses.

There are tons of references (blogs, videos etc..) out there that define and break down the JTBD framework. But essentially it is this: Customers hire your product or services to get a job done. It fundamentally flips the script on innovation by working backwards, so to speak. This means that focus starts with customer needs and unmet needs in relation to the job they are hiring your product for. Once this is fully understood, you work backwards to define the technology, features and functionality of a digital product or service. This is very much counter to how most businesses operate. Typically a company launches a product in market, then they go about seeing how well it performs and iterate and refine as needed. The JTBD framework is about shifting the focus from the product to the problem. JTBD encourages businesses to delve deeper into the core problem their customers are trying to solve.

Here are 3 things I learned from that initial Jobs to be Done experience and some key things to be aware of.

1.Integrating JTBD into user research vs JTBD as a stand alone process

Jobs to be Done is often thought of and applied as its own stand alone method, much like Design Thinking or Design Sprints. There is a level of complexity to the full throttle JTBD process, however; one of the key components and starting points are the initial user interviews. There are some important shifts and nuances that need to be incorporated into your user interview approach but JTBD is a versatile concept, and you can adapt elements of it to fit your specific research needs. By no means an exhaustive list, these are some key elements to include and consider:

1. Focusing on the core problem

2. Coming up with a “job statement”

3. Framing users as “job executors” 

4. Understanding why a product or service is being hired

5. Understanding the intended outcome

6. Exposing needs and unmet needs

2. User Interview Approach

During user interviews, It’s important to not be too literal and ask the user “what is the job you're trying to get done.” That can be a bit confusing for them to get their head around. Instead you need to be a bit more clever in your line of inquiry and ask questions that will yield the right answers that you can derive a job statement from. A job statement has 3 components: a verb, an object and context. As an example, if we look at a music enthusiast who enjoys listening to music while running, the job statement would look something like this

Notice that the context here really adds the necessary meaning to the job statement. If you removed the context from the job statement to only say “listen to music” then this becomes much too broad. Generally speaking I found that I needed to either adapt or apply nuance to my user questions so that they were optimized for gathering the necessary details I needed relevant to the JTBD framework.

3. Look for the over served and adjacent needs

While the focus of my user interviews were needs and unmet needs, a valuable piece of information consistently came out: overserved and adjacent needs. Overserved needs refers to a situation where customers feel that a product or service offers more features or capabilities than they actually need or want. Overserved can also refer to a need that is amply served elsewhere by another product or service. Adjacent needs speak to any additional opportunities outside the primary job to be done. A classic example of this is Uber Eats. The core job to be done with Uber is customers getting transported from point A to B. But this sets up a very interesting adjacent market, namely: customers getting food transported from point A to B.

I found this takeaway to be one of the most insightful pieces of information I gathered during the course of my user interviews for a mental health mobile application. Having insights into which features to prioritize and which were only secondary, tertiary or not relevant was hugely valuable to the product team. 

Summary

Understanding and meeting customer needs is more critical than ever. Interestingly, customer needs tend to be stable over time, relative to context and circumstances, which makes innovation more predictable. Traditional market research often falls short in providing actionable insights. That's where the Jobs-to-Be-Done (JTBD) framework comes into play and really unlocks opportunity and outcomes