How to Investigate Interviews Without Getting Confused? Putting JTBD Elements to Good Use

Let’s continue talking about the Jobs to Be Done framework. We already elaborated on the JTBD theory and how to implement it. Today, we’ll share our experience of how we investigate JTBD interviews and bring fruitful insights to the product, marketing, and sales teams.

Investigating and compiling the JTBD research outcomes is a tough and meticulous job. Many researchers experience hard times at this stage. And so did we. What helps tackle difficulties is a proper matrix to synthesize the jobs to be done elements. 

Advice from Dashly: if you feel your research is going the wrong way, consult the JTBD theory expert. We had a lot of difficulties after our first round of the JTBD research, so we consulted Yuriy Drogan from Growth Academy during the next one. He helped us see what we did wrong during the first round 🙂 Feel the power of networking!

From our experience, one of the most complicated Jobs To Be Done things is how you endeavor to puzzle out the approaches and notions brought to the surface. Of course, you can stick to one approach and follow its notions and ready-made artifacts. But every framework evolves during real-life research. That’s what also happens to the JTBD theory.

The Jobs To Be Done elements

Let’s consider the major elements used by the JTBD theory followers this or that way. 

Decompose your interviews first to investigate them and highlight:

• jobs; 
• contexts; 
• criteria for hiring a product; 
• progress powers;
• alternative solutions.

Job (Job to be done, JTBD) is a key notion of the framework. In his “When Coffee & Kale Compete”, Alan Klement defines a “job” as a process a customer goes through to step from his current condition into a desired one, though limitations get in their way.

There are different job levels. Defining them is what’s the most confusing thing. We’ll puzzle it out a little bit later in this article. 

Contexts are what triggers the job or the task a user needs to accomplish.

Progress powers describe the ones that encourage purchase and fears that refrain users from buying. You can also call them drivers and barriers. Marketing and sales teams knowing them can easily handle user objections.

Criteria for hiring a product are requirements for a solution. 

Alternative solutions are other possible ways to accomplish your major task; they can be either direct or indirect competitors to your product. 

Product and development teams can contribute significantly to product enhancements with the knowledge of hiring criteria and alternative solutions.  

Defining and describing the jobs

Your overall research success depends on whether you define the job that is done when users hire your product to do it correctly. 

Answer these questions to distinguish jobs and non-jobs:  

These are the parameters of the correctly identified job:

1.The job describes a task or a goal a customer wants to accomplish. 

Example: Keep oneself busy commuting to work. 

Commuting on the subway is boring — that’s an issue. You can “hire” a book or a podcast, Instagram or YouTube to resolve it. When a person takes on one of these activities, they’ll feel better. 

2.The job is described with the “verb + object + context” formula.

Note: The verb describing a job should bear a positive connotation, like “fix”, “optimize”, “accelerate”, “redeem”, etc.

Note: The verb describing a job should bear a positive connotation, like “fix”, “optimize”, “accelerate”, “redeem”, etc.

3.The job describes a change for the better.

“Configuring lead scoring” doesn’t say anything about a better life for your customer. They want it for a reason, like avoiding calls to non-targeted leads. “Cutting time spent on non-targeted leads” is a job. 

4.The job doesn’t imply a solution, it can be done in different ways.

“Run promos without developers” is a poorly defined job as it implies a solution that is “without developers”. 

Note: A product can do several jobs. But we suggest dealing with 5 at maximum for a better focus.

Job types and hierarchy

You can define jobs at different levels:

• customer emotions;
• job level (a functional task set by a customer which is partially or completely accomplished via your product). 
• task level (options for performing a job);
• subtask level (a set of actions needed to be taken to perform a job).

You may ask, “Why would I need to divide jobs into levels?” Different jobs require different granularity. For example, marketers must tell what job their product performs to acquire users. Product teams, in turn, should appreciate possible tasks and subtasks that should be accomplished for a job to be performed.  

We confused tasks and subtasks while investigating and decomposing our interviews: our subtasks were too vague. Hence, our product team (responsible for subtask-based features) didn’t know what exact actions users take to “divide the target segment from new users

Polly

Marketer at Dashly

Tasks should be worded more precisely. They should clearly illustrate how users approach their jobs, perform them, and evaluate results. 

Putting the JTBD elements to good use to investigate interviews

There’s a range of traditional jobs to be done artifacts to investigate research results. However, JTBD theory experts say they are not particularly handy. And we agree. 

You can distinguish your insights into canvases depending on the number of respondents, but this will make it hard to synthesize your outcomes. Imagine you have 40 canvases. And now imagine how hard it will be to compile them. 

A hack from Dashly on arranging and investigating the interviews: we invented a proper way to deal with research outcomes. We decompose all interviews by JTBD elements into a Notion sheet with tags that can be easily adjusted to other tasks.

We usually see one respondent’s answers in the JTBD interview templates. Notion’s superpower is that you can view the same information from different angles. It helps you find patterns without having to switch between the cards.

In our world, any element of the JTBD framework is a piece of information: a job, context, task, subtask, etc. After an interview, we list all insights in a table and tag each one. Also, we assign the respondent’s name and a quote as tags.

Let’s say you want to see all contexts mentioned during interviews. View all cards grouped by an insight tag on a board so you don’t have to switch between cards. You’ll see all elements in columns. If you want to see the whole interview, filter them by respondent name in the same view.

Any member of the Dashly team can use research results in their tasks thanks to this table and Notion opportunities. You can have a vision of all interviews, not just some of them.

Helene

Product marketer at Dashly

Download our Notion template for the JTBD interviews to view the information you get from interviews from different angles

Thanks! Your template is already in your inbox

Job story: how do I describe a task for a backlog?

The JTBD research doesn’t give you hands-on answers on what feature should be developed. It just states the task to be accomplished and defines the success criteria. There’s a great theory among the jobs to be done artifacts that helps you describe tasks before they go to your backlog. 

A job story is a phrase describing the user’s need, its context, and the anticipated result. 

Job Stories were invented in Intercom and described in their book “Intercom on Jobs-to-be-Done”. Job stories are invented with a template:

A situation is a description of the context where an issue occurs. Motivation is the desired solution to it. The anticipated result is the expected progress a person is aiming to have.

The advantage of Job story is that this framework not just describes the user’s desires, but also the context that influenced the occurrence of them.

Example: When a new large customer signs up, I want to be notified to start a conversation with them.

Based on the Job story, the PMM should develop a feature. Then, this Job story can be passed to marketing to develop materials and select acquisition channels.

A marketing message for the above Job story can sound like “Stop missing essential customers”.

A note from Dashly: Job story is a universal framework in many respects. It’s not only perfect to describe your customer’s tasks but basically every task. It facilitates team communications because you can easily describe issues, bugs, and feature requests, and set tasks using it. This small tool helps all teams develop product thinking.

JTBD is a new and rather complicated framework. You can’t just do several interviews — you need to identify jobs your customer performs using your product. And you can train this skill! Very few experts obtain fruitful insights from jobs to be done interviews on the first try. Get to know the theory, put it to good use, and enhance your product!

Collect more data about users and segment them using Dashly