Jobs to be done: the framework, with examples and job statements

Jobs to be done is a way of understanding a product through the progress a customer is trying to make, not the features you ship or the demographics of who buys. People do not want a quarter-inch drill; they want a quarter-inch hole, and really they want the shelf on the wall. Get the underlying job right and the ideas worth building become obvious. Get it wrong and you add features nobody hired your product to do.

The framework is associated with Clayton Christensen and Tony Ulwick, and it reframes the central product question from "who is our user" to "what is the user trying to accomplish, and what are they hiring to get it done." That shift sounds academic until you watch it kill a bad roadmap in one meeting. This article covers what a job is, how to write a job statement, how to run the interviews, and how to turn a job into ideas.

What is the jobs to be done framework?

Jobs to be done is a framework that defines a market as a group of people trying to make the same progress in a given situation, and it treats your product as one of several things they might hire to make that progress. A job has three parts: a situation, a motivation, and a desired outcome. It is stable over time even as the solutions change, which is why anchoring on the job outlives anchoring on a feature or a persona.

The classic illustration is the milkshake study. A fast-food chain could not figure out who bought morning milkshakes until it asked what job the shake was hired for. The answer was a long, boring commute: drivers wanted something filling, one-handed, and slow to finish. The competition was not other milkshakes, it was bananas and bagels. Once the job was clear, the improvements were obvious, and none of them were about the demographics of the buyer. Framing at that level is exactly what a good idea generator needs as its input, because a sharp job statement produces sharp ideas.

How do you write a job statement?

A job statement follows the shape "when [situation], I want to [motivation], so I can [expected outcome]." It deliberately contains no product and no solution, because the moment you name a feature you have stopped describing the job and started describing your guess at the answer. Keep it in the customer's terms and at the level of the progress they care about, not the mechanism you happen to sell.

Write several statements for the same product, because most products serve more than one job, and the jobs often compete for your roadmap. Ranking which job to serve next is itself a prioritization decision, and it feeds naturally into an opportunity solution tree, where each job becomes an outcome and the ideas hang beneath it.

How do you run jobs to be done interviews?

JTBD interviews reconstruct the story of a real purchase or switch, working backward from the moment someone started using a new solution to the first thought that set them looking. You are hunting for the trigger, the struggle, and the forces that pushed and pulled them, so you ask about the timeline of an actual decision rather than asking what features they would like. Opinions about hypothetical features are nearly worthless; the anatomy of a real switch is gold.

Good questions sound like "take me back to when you first realized the old way was not working" and "what were you using just before this." Let silences run and follow the emotion, because the real job usually hides behind an offhand complaint. These are structured discovery conversations more than surveys, and teams that run a lot of them often systematize the intake and scheduling the way a good client discovery process does, so the interviews actually happen instead of always being next week's plan. A handful of deep interviews beats a hundred shallow survey responses for finding the job.

How do you turn a job into product ideas?

Once the job is clear, generate ideas against the outcome, not the feature you already had in mind. Take the job statement and ask what would help the customer make that progress faster, more reliably, or with less anxiety, and let the answers range wider than your current product. This is where divergence pays off: the job defines the target, and structured ideation fills the space of ways to hit it, before you narrow to what is buildable.

Run the job through several angles deliberately. Invert it to find everything that currently blocks the progress, then design those blocks away. Borrow from how other industries serve the same underlying job. Then cluster the ideas by the part of the job they serve and score them, so you build the two directions that move the outcome most rather than the first feature that came to mind. Product teams often fold this straight into their roadmap process, which is why the product-team workflow starts from outcomes rather than a feature wishlist.

What are the limitations of jobs to be done?

The main limitation is that JTBD is a lens, not a measurement system. It is excellent at reframing what you are building toward and poor at telling you how big the opportunity is or which job pays best. A perfectly articulated job can still describe a tiny or unprofitable market, so JTBD needs to sit alongside real sizing and business judgment rather than replace them. The framework points you at the right target; it does not tell you whether the target is worth hitting.

The second trap is over-formalizing it. Some teams turn JTBD into a heavyweight ritual of templated statements and taxonomies that produces documents nobody uses. The insight is simple and most of the value comes from a few honest interviews and one well-written job statement. Treat it as a thinking tool that keeps you anchored on customer progress, use it to sharpen the input to your ideation and roadmap, and do not let the vocabulary become the deliverable. The goal is better products, not a tidier framework.

The short version

Jobs to be done reframes a product around the progress a customer is trying to make, expressed as a situation, a motivation and an outcome, with no feature baked in. Write the job statement in the customer's words, find it through interviews that reconstruct real switches, and then generate and score ideas against the outcome rather than your existing feature list. Anchor on the job and the roadmap gets clearer; anchor on the feature and you keep building things nobody hired you to do.