Jobs to Be Done and Behavior Data — Finding What Users Are Really Trying to Do

Short answer: jobs to be done treats a purchase as "hiring" a product to make progress in a particular situation. Interviews reveal the job and the circumstances. Behavior data shows which jobs people actually attempt in your product, in what order, and where they fail. Use recordings to see workarounds and unexpected uses, which often point to a job you had not designed for.

Table of Contents

1. The Idea
2. What Interviews Give You
3. What Behavior Gives You
4. Finding Jobs in Session Data
5. From Jobs to Decisions
6. Key Takeaways

The Idea

People do not want a product for its own sake. They want to get something done. The framework's usual form is a statement:

When [situation], I want to [motivation], so I can [outcome].

Examples:

• "When conversion drops after a release, I want to see what users experienced, so I can fix it before it costs a week."
• "When a customer says something is broken, I want to see their session, so I can answer without asking them to reproduce it."

The same product is hired for different jobs by different people. A session replay tool is hired by an engineer to debug, a marketer to improve a landing page, and a founder to understand new users.

The value of the framing is that it shifts attention from features and customer demographics to situations and outcomes. Two customers with nothing else in common can share a job.

What Interviews Give You

Jobs are discovered mainly by talking to people about a real, recent decision.

• The trigger. What happened that made them look for something?
• What they used before. A competitor, a spreadsheet, or nothing.
• What they considered and rejected.
• What almost stopped them.
• What "done" looks like to them.

This is context no analytics can supply (feedback and behavior).

What Behavior Gives You

Interviews are few and reconstructed from memory. Behavior data is plentiful and direct.

Finding Jobs in Session Data

1. The first action after arriving

What a returning user does first is the job they came to do. If most sessions begin by going to the same report, that report is the job. Group sessions by their first meaningful action.

2. Repeated sequences

A sequence of five steps performed again and again by the same users is a job your product supports clumsily. It is a candidate for a single action.

3. Workarounds

• Exporting data to finish the task elsewhere.
• Copying values between two tabs of your product.
• Using a text field to store something it was not meant for.
• Creating dummy records to group things.

Each workaround is a job with no direct support. These are the strongest signals for a roadmap.

4. Unexpected paths

A journeys report from a key page often shows a route nobody modelled. DeepSync's docs note that journeys frequently reveal a route you never thought to turn into a funnel (journeys).

5. Abandoned attempts

A user opens a feature, tries something, fails, and leaves. They had a job. The product did not do it.

6. Entry points

The page someone lands on, and the search query that brought them, hint at the job. A visitor landing on a comparison page has a different job from one landing on a setup guide (search queries by landing page).

Tag sessions so jobs can be compared:

deepsync("track", "job_started", { job: "debug_issue" });

Then interview a few of the people you watched. "I noticed you export this report every Monday. What happens to it next?" is a question that could only come from behavior, and its answer could only come from a conversation.

From Jobs to Decisions

Jobs also sharpen positioning. Describing your product by the job it does, in the words customers used in interviews, is clearer than a list of features, and it is what search engines and AI assistants pick up (writing for citation).

A caution: behavior shows the jobs people attempt in your product. It cannot show the jobs they never tried because they assumed you could not help. For those, you need interviews with people who chose something else.

Key Takeaways

• A job is the progress a customer wants in a situation.
• Interviews give context; behavior gives frequency, order, and failure points.
• Workarounds and repeated sequences reveal unsupported jobs.
• Use behavior to choose who to interview and what to ask.

Conclusion

Customers hire your product for reasons that are often different from the ones you built it for. Their sessions show what they are trying to do. Ask them why, and build for that.

Start free with DeepSync.