Jobs to Be Done

Someone opens Google Maps.

They are not thinking:

I want to consume a mapping feature.

They are trying to:

Get to dinner without getting lost.

That progress is the useful thing to understand.

Jobs to Be Done is a way of asking:

What progress is this person trying to make in this situation?

The “job” is not their job title.

It is what they are trying to accomplish.

A user buys noise-cancelling headphones.

Possible job:

Help me focus in a noisy office.

The product is headphones.

The underlying job is concentration.

That distinction can open up better product thinking.

The same person can use the same product for different jobs.

Headphones on a plane:

Help me block engine noise.

Headphones at the gym:

Give me music without cables getting in the way.

Understanding the situation makes the need more precise.

Suppose users ask for:

A dashboard.

Instead of starting with dashboard features, ask:

What decision are they trying to make with this information?

Maybe they want to identify underperforming stores.

Maybe they want a weekly executive update.

Those are different jobs.

You do not need to force every problem into a formal sentence template.

The useful habit is simpler:

What progress is the person actually trying to make?

Users do not wake up wanting features.

They are trying to make progress in a situation.

Understand that progress before designing the solution.