Jobs to Be Done in Design: How to Stop Designing Features and Start Solving Problems

## Where did the framework come from

The idea was formulated by Clayton Christensen at Harvard based on observations of why people switch from one product to another. The most famous example from his research is a milkshake in a fast food chain.

The chain wanted to boost sales of cocktails and asked customers what to improve: taste, size, price. I got standard answers. Then I looked at it differently: in what situation do people buy a cocktail and why? Most of the customers are morning commuters. They hired a cocktail to occupy their hands and mouth on a long, boring road and not get hungry until lunch. The competitors of the product are not other cocktails, but bananas, bars and coffee. An improvement that worked: the cocktail made thicker and added pieces of fruit to drink longer.

No focus group asking what to improve would give this insight.

## Three layers of any job

Each task that the user solves through the product works on three levels simultaneously. Designing only at the functional level means losing half the picture.

Functional. What a person does literally. Sends a file. Booking a table. Paying the bill. This is seen in analytics and usability tests.

Emotional. How he wants to feel in the process and after. I'm sure not to screw up in front of the team. Calm down, don't keep it in your head. Gordo did it himself, did not ask for help.

How he wants to look in the eyes of others. Professionally. Careful. Modern.

Example: A person is looking for a training app. Functional job – track progress and get a plan. Emotional - to feel that moving towards the goal, and not stomp in place. Social - to look like a person who takes care of himself.

An application that solves only the functional level is a tracker. The app that falls into all three is the product that comes back to.

## How to formulate a job statement

The formula used by most JTBD practitioners is:

** When [context], ** I want [action], ** to [desirable outcome].

The three rules of a good job statement:

The first is no mention of the product or feature inside. “I want to use a dashboard to track metrics” is not a job statement, it’s a feature description. “When I’m preparing to meet an investor, I want to quickly understand how the product is doing so I don’t look like a person who doesn’t know their numbers.”.

Second, context is more important than person. The same person hires the product differently in different situations. The manager checks the dashboard on Monday morning and the supervisor checks the dashboard five minutes before the presentation - two different jobs with different requirements for speed, depth and format.

Third, the wording should remain true even if your product disappears. Job describes the progress of the user, not the interaction with the interface.

Some examples for typical products:

The user wants to add a task to the list
Well, when you have a thought in your head that you can't lose,
I want to record it in seconds to get back to that.
What I was doing and not keeping it in my head.

The user wants to see the payment history
Well, when it comes to accounting,
I want to find the right payment in less than a minute.
It doesn’t look like someone who doesn’t control spending.

Bad: The user wants to share the file
Well, when you need to show the work to the client,
I want to send a link that he opens without registration,
So he sees the result, not the form of the entrance

## How to Find Jobs: Three Methods

### Switching interview

The most effective method in JTBD practice. Not “what do you like” but “tell me about the moment you decided to try this product.” Going back, what happened before? What's the trigger? What was seen as an alternative? Why did you choose this?

It’s hard for people to articulate what they want, but it’s easy to remember a specific event. The switching interview pulls out the real context, not the rationalization after the fact.

Three questions to start with:

- Remember the day you first used the product.
What happened that day?
- What have you done to solve the same problem?
- Was there a time when you hardly used it?

### Contextual observation

You see people working in their environment, not in the lab. People don't talk about the workarounds they invented. They don’t say they open Excel because the main product doesn’t have the right filter. They don't mention taking a picture of the screen because exports are too slow.

Contextual observation reveals jobs that will never surface in interviews.

### Job mapping

You take one job and break it down into steps: what the person does before, during and after. At every step you ask: where is more time spent than it should be? Where does uncertainty arise? Where does a person go around?

This is not a user path map – CJM describes interaction with the product. A job map describes the work a person does, whether or not your product exists.

## How JTBD Changes Solutions in Practice

In the research phase. Instead of asking “what features do you need” you ask “in what situation do you use it and what would have happened if it didn’t exist.” The difference in the quality of insights is fundamental.

At the design stage. Each decision is checked by the question: what job does it help to accomplish? If there is no answer, the solution is in question. This quickly exposes the features that were added because “competitors did” or “asked the CEO.”.

**Prioritization phase. ** Instead of arguing “what’s more important,” the team looks at jobs that are poorly closed. The metric is how important the job is to the user and how satisfied they are. High importance + low satisfaction = opportunity.

At the testing stage. The usability test shows whether a person can execute a script. The JTBD test shows whether a product solves a real problem in a real context. These are different questions with different answers.

## Typical errors

*Pushing the export button is not a job. Prepare a report before a meeting without switching between five tools.

Ignoring the emotional context. A product that solves a functional job but ignores the emotional loses to a product that does both. Anxiety, insecurity, the desire to look competent are not soft things, they are part of the task.

** Collect jobs and put in a desk.** Job statements are useless as an artifact. They only work if the team returns to them at every design review and every planning.

Try to close all jobs at once. It is better to close one or two core jobs deeply than to close ten. Products that try to hire for everything lose to specialized ones.

## How AI Accelerates JTBD Research

JTBD works on qualitative data – interviews, observations, transcripts. Historically, analysis has been a bottleneck: 20 interviews yield hundreds of pages of text, manual coding takes three to four weeks. AI does not replace the researcher, but compresses this cycle radically.

Here are the specific places where AI is built into JTBD workflow.

### Preparation of a guide for a switching interview

A JTBD interview is different from a regular Discovery interview. It has a specific structure: six timeline stages (first thought → passive search → active search → solution → first use → result) and four forces that move or inhibit switching. Building a guide that covers all stages and does not miss the necessary probing questions is a task for several hours.

Prompt for Claude:

You're an experienced JTBD researcher. Create an interview guide
We're going to switch using Bob Mousta's methodology.

Product: [name and short description]
Audience: [Participants]
Purpose: to understand why users switched from [alternatives]
on our product in the last 3 months.

Turn on:
Warm up and install trust (5 minutes)
- Six stages of the timeline with 3-4 prodding questions on each
- Block of four forces: push, pull, anxiety, habit
- Closing and next steps

Questions should be open, without mentioning product features.

### Transcript cleaning and preparation

The raw transcript from Otter, Fireflies or Zoom is noise: inconsistent speaker labels, parasitic words, time stamps that break structure. Before analysis, the transcript must be put in order.

Prompt:

Clear this transcript of the JTBD interview:
Normalize speaker tags: interviewer → And, participant → U
- Remove the parasitic words (well, like, here, sort of) keeping the meaning.
Keep the emotional markers: [laughs], [pause], [unsure]
Keep verbatim quotes intact – they will go into job statements
- Remove the time stamps, structure the lines.

[Insert transcript]

### Extracting job statements from transcripts

The most time-consuming part of analyzing JTBD is finding patterns through a few interviews. AI works with a large amount of text at the same time and sees repetitive motifs that, when manually worked, are easy to miss.

Prompt for one transcript:

Analyze the transcript of the JTBD interview.

Extract:
1. Job statements: When [context], I want [action],
so that [the result] is separately functional, emotional, social
2. Switching triggers – what exactly triggered the search for an alternative
3. Attraction forces to a new product (pull)
4. Braking forces – anxiety and habits that prevented you from switching
5. Direct quotes for each item

Don’t add interpretations, just what the participant said.

[Insert transcript]

Prompt for synthesis by several transcripts:

Below are purified transcripts of [N] JTBD interviews.
Find the cross-cutting patterns:

Top 3 jobs by frequency of mention with quotes from different participants
- Repeated switching triggers
- Common Anxieties That Retarded Decision
- Contradictions between participants – where opinions differ
- Unexpected findings that occurred in 1-2 participants
but seem significant

For each pattern: how many participants mentioned it
and at least one direct quote.

[Put transcripts in]

### Validation of job statements

Write a job statement – check it out before you build on it.

Check these job statements for quality criteria:

- No mention of product or feature
- Context concrete, not abstract
- The result describes the user’s progress, not interaction with the interface.
The wording remains correct if our product disappears.

[insert job statements]

For each: estimate ok/needed edit + specific sentence
How to improve if necessary.

### Important border

AI works well with volume and structure. He finds that eight of the twelve participants mentioned the anxiety associated with switching to a new instrument. But why this anxiety is important for your product, what to do about it, and which decision is more important than others is the interpretation that remains for the researcher.

Use AI to free up time for thinking, not to replace it.

## Checklist: how to apply to the next project

Study
● Conduct a minimum of 5 interviews to switch
● Write job statements by formula: When / I want / I want
● Check: the wording does not mention the product or feature

Designing
● Every new decision to check: what job does it close?
● For key screens, define a functional and emotional job
● Remove from the backlog features for which there is no answer to this question

Prioritization
● Rate jobs by matrix: importance × current satisfaction
● Focus on jobs with high importance and low satisfaction

Testing
● Check whether the user can execute the script
(a) “Does it solve its real problem in a real context?”