Nobody Wakes Up Wanting Your Product. Here Is What They Actually Want.

Nobody wakes up in the morning and says "I really want to buy a project management tool today." That thought has never crossed anyone's mind in the history of software.

What they actually think is: "I am terrified my team is going to miss this launch deadline and I am going to be the one who has to explain why."

That gap, between what we think users want and what they are actually feeling, is where most product decisions go wrong. And there is a framework built entirely around closing it. It is called Jobs to be Done, and once you understand it, you will never look at a user interface the same way again.

What Is Jobs to be Done?

Jobs to be Done, usually shortened to JTBD, is a framework for understanding why people buy and use products. The core idea is simple: people do not buy products because of what those products are. They buy them because of what those products help them accomplish or stop feeling.

The word "hire" is intentional here. When a user downloads your app or signs up for your tool, they are hiring it to do a specific job. That job is almost never the surface-level task the product is named after. It is the underlying anxiety, desire, or outcome driving the behavior.

The framework was developed by Clayton Christensen, a Harvard Business School professor, and has since become one of the most practically useful lenses in product design.

Why This Changes How You Think About UX

Here is the problem with most product design. Teams build around features. They ask "what should this product do" and end up with a list of capabilities: task management, file sharing, reporting, notifications. Then they design an interface that organizes those capabilities in a logical way.

Logical. But not human.

Because users do not open your product thinking about capabilities. They open it carrying a feeling. Deadline anxiety. Communication chaos. The embarrassment of showing up to a meeting without the right information. Your product either relieves that feeling quickly or it does not. If it does not, they churn. Not because your features were bad. Because the interface was optimized for the wrong thing.

JTBD forces you to design for the feeling first and the feature second.

How to Write a Jobs to be Done Statement

A JTBD statement follows a specific structure. Memorize it.

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

The situation is the trigger: the specific moment or context that sends the user to your product. The motivation is what they are trying to do or stop feeling in that moment. The expected outcome is what success looks like for them.

Here is how this works for a tool you already know. For Slack, a weak product description says "team messaging platform." A JTBD statement says: "When I am working remotely and need a quick answer from a colleague, I want to ask without scheduling a meeting, so I can keep my momentum and not lose the thread of what I was doing."

That statement contains everything a product team needs to make good design decisions. It tells you the trigger, the emotional stakes, and the definition of success from the user's perspective.

How to Apply JTBD to Your Own Product

Start by writing the JTBD statement for your core user. Not a persona. Not a demographic. The statement. The specific situation, motivation, and expected outcome.

Once you have it, hold it up against your current interface and ask one question: does every design decision in this product help the user get that job done faster?

That question is ruthless and that is the point. If the job is "quick communication to maintain momentum" then the speed at which the chat box loads matters more than any text formatting option you could build. If the job is "avoiding deadline embarrassment" then a clear, immediate overview of what is late matters more than a beautiful data visualization of historical project velocity.

JTBD does not just tell you what to build. It tells you what to cut. The features that do not serve the job are the features getting in the way of it.

The Practical Test

Take any feature on your current product roadmap. Ask: which part of the JTBD statement does this serve? If you cannot answer that clearly, the feature is probably solving a problem that exists on your side of the table, not the user's.

Good UX is not about adding more. It is about removing everything that sits between the user and the outcome they hired your product to deliver.

That is the whole framework. Find the job. Write the statement. Design for the outcome, not the capability. Cut everything that does not serve it.