Jobs to Be Done: Using JTBD to Decide What to Build

"People don't want a quarter-inch drill; they want a quarter-inch hole." That line captures the whole idea behind Jobs to Be Done (JTBD): customers don't buy features, they hire your product to make progress on a job. Reframing your thinking around the job — rather than the feature — is one of the most powerful ways to decide what to build. Here's how JTBD works and how to use it.

What Jobs to Be Done means

JTBD says every time someone uses your product, they're trying to get a "job" done — to make some progress in their situation. The job is stable and solution-agnostic; the features that satisfy it change. People "hired" taxis, then Uber, then maybe self-driving cars — same job ("get me across town reliably"), different solutions.

A job usually has three dimensions: the functional (the practical task), the emotional (how they want to feel), and the social (how they want to be seen). Great products serve all three.

Why it changes what you build

The trap JTBD saves you from is building solutions to stated requests without understanding the underlying job. A user asks for "a dropdown to filter by date." If you just build the dropdown, you might miss that the job is "quickly find last month's transactions to reconcile my books" — which a smart default view or a saved filter might serve far better.

This connects directly to how you read feature requests. As we cover in feature request examples, the best requests state the problem, not just the solution. JTBD is the discipline of always asking "what job is this request really about?" — which frees you to solve it in the best way, not just the way the user imagined.

How to uncover the job

Ask about the situation, not the feature. Instead of "what feature do you want?", ask "what were you trying to do when you needed that?" and "what did you do just before and after?" The context reveals the job.

Look for the "hired" and "fired" moments. Why did they start using your product (what job did it solve)? When they stop using a feature or switch tools, what job went unmet? Your feedback board and churn signals are full of these clues.

Interview for progress. Short conversations asking "what were you ultimately trying to achieve?" surface jobs that surveys miss. This is core to product discovery.

Using JTBD to prioritize

Once you know the jobs your product serves, prioritization gets clearer: build the features that best advance the most important, most underserved jobs. Combine JTBD (which tells you what job matters) with a scoring framework like RICE (which helps you rank the solutions). JTBD keeps you solving real problems; the framework keeps you efficient about it.

Start with the jobs your users describe

Every feature request is a clue about a job. Create a free feedback board on FeatureRequest, gather what users are trying to accomplish, and use the JTBD lens to build the solutions that actually get their jobs done.