Jobs to Be Done

What is Jobs to Be Done?

Jobs to Be Done is the idea that customers don't buy products, they "hire" them to make progress on something in their life, and understanding that underlying progress tells you more about what to build than any demographic or persona ever will. It's a core input to Product Discovery: before you can decide what to build, you need to know what job people are actually trying to get done.

The origin of the term is genuinely contested, and the two camps mean different things by "job." Tony Ulwick developed his version starting in 1990, applying Six Sigma-style process thinking to innovation, and formalized it as Outcome-Driven Innovation. In Ulwick's framing, a job is a functional activity with measurable outcomes, something like "prepare a hot beverage for consumption," broken into steps a customer executes and metrics they use to judge success. Clayton Christensen, who Ulwick introduced the framework to roughly a decade after his 1990 breakthrough, popularized a different reading. Christensen's version, laid out most fully in "Competing Against Luck," defines a job as the progress an individual seeks in a given circumstance, closer to a narrative about motivation than a checklist of steps.

The example everyone remembers is the milkshake study, where researchers watched a fast-food chain's customers for hours and found something the surveys had missed: 40 percent of milkshakes were purchased in the morning by commuters who ordered them to go. The milkshake wasn't hired to taste good. It was hired to make a long commute more bearable and to keep a hand busy without making a mess. Christensen summed up the shift in method this way: "The jobs-to-be-done point of view causes you to crawl into the skin of your customer and go with her as she goes about her day" (HBS Working Knowledge). Produck uses this progress-centered version of the definition, because it's the one that keeps you asking why a customer wanted something instead of stopping at what they clicked.

Why it matters for product-market fit

Most teams collect feedback as a list of requests: "add dark mode," "let me export to CSV." Jobs to Be Done is the discipline that stops you from building the request literally and asks what progress the customer was actually trying to make when they asked for it. That distinction sits right at the seam between Listen and Diagnose in Produck's loop.

Listen captures the raw request. Diagnose is where Jobs to Be Done earns its keep: you take a pile of surface-level asks, group them by the underlying job, and separate the customer who wants CSV export because they need one clean report for a board meeting from the one who wants it because they don't trust your in-app numbers. Those are different jobs wearing the same feature request, and they lead to different fixes. Decide is where you weigh which jobs are common enough and painful enough to act on. Ship closes the loop, and the job framing is what tells you whether the shipped feature actually resolved the progress people wanted, not just whether it shipped.

This is also where a User Interview earns its keep. A feature request tells you the solution someone imagined. A jobs-focused interview, asking what was happening right before they went looking for a fix, surfaces the circumstance and the progress underneath it. Pair that with the Kano Model when you're deciding priority: Kano tells you whether a feature will delight or merely satisfy, but Jobs to Be Done tells you which job that feature is actually serving, so you don't optimize delight for a job nobody was hiring you for. We've written more about why teams skip this diagnostic step entirely and jump straight from raw feedback to a roadmap, and why that shortcut is the real reason most teams never find product-market fit.

When it works, and when it doesn't

It works when

• You have a recurring pattern of similar-sounding requests and need to know if they're actually the same underlying job or several different ones wearing the same words.
• You're deciding between two competing feature ideas and want a tiebreaker rooted in customer progress rather than internal opinion.
• You're entering a market segment you don't understand yet and need a vocabulary for what "success" means to that customer, before you write a single spec.
• You're trying to explain a churn pattern that your usage analytics can describe but can't explain, like a segment that adopts fast and then quietly disappears.

It falls short when

• You need day-to-day triage of bugs and small requests. Running every ticket through a jobs interview is slow, and most tickets don't need it.
• Your product is brand new and you don't have enough real usage yet to distinguish a genuine recurring job from a one-off request from a single vocal user.

How to apply it

1. Pull five to eight recent, similar-sounding requests from your feedback inbox, the kind that sound like the same ask phrased differently.
2. For each one, go back to the customer and ask what was happening in their day right before they went looking for this. Not "why do you want this feature," but "what were you trying to get done."
3. Write the job as a sentence about progress, not a feature: "get a clean number I can defend in a board meeting" rather than "wants CSV export."
4. Group the requests by job, not by the literal words used. You'll usually find two or three jobs hiding inside what looked like one request.
5. Rank the jobs by how often they show up and how painful the current workaround is, then decide which one you're actually building for.
6. Ship the narrowest version that resolves the job, and check back with the same customers to confirm the progress actually happened, not just that the ticket closed.