Concept · Strategy

Jobs to be done

Reconstruct a recent choice, then test which obstacle prevents the customer from making progress.

Understand the situation behind the choice.

A product manager hears that customers need a better shared folder. The request seems concrete until the team must choose between extra storage, easier external sharing and tighter permissions. Those investments solve different problems. A fictional designer sending work to a client tonight may need the client to open the correct file without installing anything. A fictional administrator may need to prevent that same link from spreading. The object is the same; the situation and desired progress differ.

In one sentence

Jobs to be done treats the customer’s situation, desired progress and competing alternatives as the unit of inquiry.

Jobs to be done begins with that distinction. The Christensen Institute’s foundational account connects choices to progress in circumstances and to functional, social and emotional forces. Use the idea to reconstruct an actual episode: what changed, what the person tried, who could block the choice, and what counted as a satisfactory finish. Calling a feature a job does not answer those questions. [Theory](https://www.christenseninstitute.org/theory/jobs-to-be-done/).

The mechanism is a change in the unit of competition. When the task is a deadline handoff, an email attachment, a client portal, a shared link and a phone call confirming receipt may compete. When the task is recovering personal files after changing devices, those substitutes may be irrelevant. These are proposed alternatives to investigate, not evidence of observed Dropbox switching. Product-category labels can hide this distinction, while a situation makes it visible.

Three questions that change the product decision

Functional, emotional and social dimensions should produce separate observations. They need not become three new features.

Complete the handoff

Functional progress describes an observable finish. For the fictional review task, the relevant person can open the intended file and act on it. A larger storage allowance is valuable only if capacity is the bottleneck.

Reduce uncertainty

Emotional progress might mean avoiding anxiety about whether a client has received the work. Treat that as a research hypothesis: ask which evidence provides reassurance and observe whether the sender still sends a second message.

Meet a social obligation

Social progress might involve showing colleagues that the sender controlled the deadline and access. This can conflict with frictionless sharing. Observe the stakeholder’s response rather than assuming all convenience is welcome.

A continuum, not a switch

Research becomes more useful as it specifies the trigger, acceptable outcome, alternatives and observed behavior; the confidence comes from evidence, not the elegance of the job statement.

LowFeature requestHighObserved choice in circumstances

“A useful job hypothesis changes what you would observe next.”

Why it matters

Start with a recent decision rather than asking people what they generally prefer. Reconstruct the trigger, the previous workaround, the moment the workaround failed and the people who participated. Ask for the artifact where appropriate: the approval message, error screen or final delivery. Interview a non-buyer facing the same situation as well as a successful buyer. Otherwise the research can explain enthusiastic adopters while missing the barrier that matters commercially.

Then turn the account into a falsifiable proposition. For the hypothetical designer, predict that an easier recipient experience will increase completed review handoffs, without weakening the agreed access controls. Observe whether the recipient opens the intended file, whether an avoidable follow-up is needed and whether the sender repeats the workflow on a subsequent project. More uploads would be a weak test: uploads can rise while the client still cannot act.

The commercial question comes later. A repeated job can be important and still produce little willingness to pay because an acceptable workaround is free or already included in another tool. Compare actual choices under a clear offer, and retain the customer’s total effort alongside the supplier’s price. This is a proposed research sequence, not a measured guarantee that interviews increase sales.

Real-world examples

The same concept shows up in different ways across industries.

DropboxOne architecture, several plausible jobs

→

Dropbox’s filing described private, shared and managed team folders, plus links for recipients who were not users. That supports several use hypotheses. Its paid-license series supplies scale, not motives. The linked case asks which evidence would distinguish a project handoff from retrieval, capacity and control needs. [Product description](https://www.sec.gov/Archives/edgar/data/1467623/000119312518055809/d451946ds1.htm). [Read the case](/en/breakdowns/shared-folder-customer-job).

When it breaks

A compelling story can conceal an inconsistent market. One deadline episode does not show how often it occurs, which firms experience it or how costly it is. Count occurrence separately from vividness. Check whether the proposed segment shares the same trigger and constraints; job labels such as ‘confidence’ can cover incompatible reasons for buying.

The strongest competing explanation for a collaboration purchase may be a procurement mandate, bundle price or required compatibility. The user can value a handoff improvement while the buyer chooses another provider for those reasons. Record whose progress matters and whose approval is required. A jobs lens helps find demand, but does not remove organizational authority or distribution constraints. Dropbox’s filing names security, interoperability and price among its competitive factors. [Competitive risks](https://www.sec.gov/Archives/edgar/data/1467623/000119312518055809/d451946ds1.htm).

A counterexample is a regulated team whose first requirement is centralized control. The fastest anonymous link could harm its desired progress. A personal user looking for recovery after a device failure also need not value group collaboration. Keep these hypothetical situations separate rather than stretching a universal job statement until every feature fits.

Key takeaways

01
Write the job as a situation and progress, then name a plausible competing workaround. State which part is observed and which remains a hypothesis.
02
Choose a behavioral outcome that would distinguish your proposed mechanism from capacity, pricing or procurement explanations. Record unsuccessful episodes as carefully as successful ones.
03
Use the linked Dropbox case to practice the evidence boundary: shipped features can support a job hypothesis, while aggregate paid licenses cannot verify it.

Sources

Jobs to Be Done Theory · Christensen Institute. Definition, paragraphs 1–3; Helpful Tools, “Jobs is not asking why someone made their decision,” paragraphs 1–2
Dropbox 2018 Form S-1: folder types · Dropbox / SEC. Business, Our Product, Share / Folders and Shared links, printed pp. 100–101; HTML passages beginning “Folders. There are three types” and “Shared links. Users can share”
Dropbox 2018 Form S-1: paying users · Dropbox / SEC. Key Business Metrics, Paying users, printed p. 13 (repeated in MD&A p. 65); table as of December 31, 2015, 2016, 2017 (6.5, 8.8, 11.0 million); definition immediately above
Dropbox 2018 Form S-1: competitive risks · Dropbox / SEC. Risk Factors, “We operate in competitive markets”, printed pp. 19–20; paragraph naming cloud-storage and collaboration competitors and competitive-factor bullets