Users do not buy products. They hire products to do a job. That distinction — deceptively simple — changes every architectural decision a technical leader makes.
The Jobs-to-Be-Done framework, developed by Clayton Christensen and colleagues, holds that the fundamental unit of user value is not the feature and not the product. It is the job: the specific progress a user is trying to make in a specific circumstance. When you understand the job, you understand what the system must actually do, and you can evaluate architectural decisions against that criterion rather than against an internal standard of technical correctness.
Technical leaders who learn to think in jobs build systems that solve the right problem well. Technical leaders who do not build systems that solve the wrong problem perfectly.
You have seen abstraction before in its algorithmic form: a sorted array abstracted into a search interface, a graph abstracted into a routing API, a hash function hidden behind a key-value store. Each boundary separates what a caller can do from how the system does it. This chapter applies the same logic to user intent. The Jobs-to-Be-Done framework draws an abstraction boundary between the job — the outcome a user is trying to achieve — and the product — the mechanism hired to achieve it. A product that exposes its internal implementation rather than the job is like an API that leaks its data structures: technically correct, but harder to use than it should be.
A job has three components: a functional dimension (the practical outcome the user wants), an emotional dimension (how the user wants to feel while accomplishing it), and a social dimension (how the user wants to be perceived). Most engineering teams think only about the functional dimension. The other two are real, measurable, and architecturally consequential.
Consider a writing assistant. The functional job is “help me produce text faster.” The emotional job is “help me feel like a competent writer rather than a person struggling with a blank page.” The social job is “help me produce work that others will respect.” These three jobs lead to different architectural requirements. The functional job demands low latency. The emotional job demands graceful handling of partial or incomplete input — a system that refuses to engage until the user provides a complete, well-formed prompt fails the emotional job even if it succeeds at the functional one. The social job demands quality over speed: a fast answer that is incorrect or incoherent fails the social dimension even if it satisfies the latency SLO.
The architecture that optimises for the functional job alone will miss the other two.
Three contrasting jobs illustrate how the same broad category — “writing assistant” — produces radically different system requirements.
The job “help me write faster” requires synchronous AI completions with a latency SLO in the range of 200–500 milliseconds. Above that threshold, users perceive a delay and the tool feels slow. This job demands inference infrastructure optimised for speed, small model sizes or aggressive caching, and streaming outputs so the user sees tokens appearing rather than waiting for the full completion.
The job “help me write better over time” is a different system entirely. Better-over-time requires feedback loops: the system must observe what the user accepted and rejected, store that history, use it to calibrate future suggestions, and surface patterns in the user’s writing that the user themselves may not have noticed. This job is primarily asynchronous. The user does not need the feedback in real time; they need it to be accurate and accumulative. The architecture is a data pipeline, not a latency-sensitive service.
The job “help me not lose my work” is durability-first. The system must acknowledge writes only after they are committed to durable storage. Eventual consistency is unacceptable. Sync-before-acknowledge is the design pattern. Latency is secondary to durability.
These three jobs look similar on the surface — they are all “writing assistant” features — but they produce architectures that share almost nothing. A technical leader who does not distinguish between them will build a single system that does all three badly.
The same logic applies to API design. An API that exposes what the system does — “create entity,” “update entity,” “delete entity” — forces the caller to understand the system’s internal model. An API that exposes what the user wants to accomplish — “publish article,” “retract article,” “request review” — lets the system evolve its internal model without breaking callers. The unit of the API surface is the job, not the implementation.
GitHub’s pull request model was designed around the job “coordinate code changes across a team.” The job is not “upload a diff.” The difference matters architecturally. Uploading a diff requires storage and retrieval. Coordinating changes requires status tracking, notification infrastructure, review state machines, merge conflict detection, and CI/CD integration hooks. Each of these is a separate system. The job definition determined the scope.
Dropbox solved the job “access my files from anywhere without thinking about it.” The key phrase is “without thinking about it.” Users do not want to manage sync. They want sync to happen. The architectural consequence is that the sync engine must be invisible: it must handle conflicts silently, recover from interrupted syncs, and never require the user to make a decision about file state. An architectural choice that exposes sync conflicts to users as a decision they must make fails the job, even if it is technically correct.
Stripe solved the job “accept payments without becoming a payments company.” The job has a strong negative component — “without becoming” — which means the architecture must hide complexity, not expose it. Every API decision that forces the integrating developer to understand payment rails, fraud models, or compliance requirements is an architectural failure relative to the job.
Foursquare’s 2014 split into two products — Foursquare and Swarm — is the clearest example in recent product history of JTBD analysis producing an irreversible architecture decision. Foursquare had been a single product that did two things: it let users check in to locations, and it let users discover places. The two jobs looked related. Both involved locations. Both involved the social graph. But they were structurally different.
The check-in job was: “tell my friends where I am.” It required social graph infrastructure, notification delivery, and a sharing model. Its value came from the presence of friends on the network. Its users were social by intent. The discovery job was: “find the best pizza near me right now.” It required dense local data aggregation, review quality models, and geographic ranking. Its value came from the density and accuracy of local data. Its users were functional by intent — they wanted a result, not a social interaction.
The single-product architecture served both jobs poorly. The check-in feature cluttered the discovery experience with social noise. The discovery feature made the check-in product feel impersonal. The data model was a compromise between what the check-in job needed (social graph traversal) and what the discovery job needed (geographic density ranking). When Foursquare’s leadership committed to the job separation — Swarm for check-ins, Foursquare for discovery — the architectural consequences were immediate. Swarm was rebuilt around social graph infrastructure. Foursquare’s discovery product was rebuilt around local data quality and ranking. Each product became substantially better for its job within eighteen months of the split, because the architecture no longer had to serve two structurally incompatible jobs simultaneously.
The decision to split was made against significant resistance — “we’ll look like we’re giving up,” “users will be confused,” “we’ll lose the network effect from combining both audiences” — and the team’s internal data showed that the majority of users did not actively use both features. That data, interpreted through the JTBD framework, made the architectural decision unavoidable. The question was not whether to split, but how fast.
Designing to the job rather than to the feature increases the scope of the initial system and slows early velocity. A team that builds “create, read, update, delete” for entities ships faster than a team that designs around jobs-to-be-done. The cost of the job-oriented approach is upfront. The benefit is that the system remains correct as the product grows, because the design was calibrated to user intent rather than internal convenience.
The opposing tradeoff is over-indexing on the job definition. Jobs are discovered, not invented. If the team has insufficient data about actual user behaviour, a job-oriented design is speculation formalised as architecture. The risk is designing a system to serve a job that users do not actually have, or that they have in a different form than the team assumed.
Teams that skip job analysis build systems that are coherent internally but incoherent from the user’s perspective. The features make sense given each other. They do not make sense given the user’s actual goal. This is the most common form of product-architecture misalignment: technically correct, user-irrelevant.
A related failure is job substitution. The team identifies a job, designs a system to serve it, ships the system, and then gradually adds features that serve a different job. Over time, the system serves neither job well. The architecture was designed for “write faster” and feature requests have added “remember my preferences,” “suggest sources,” and “track my progress.” Each feature is small. Together, they change the job the system is serving without changing the architecture to match.
Concept: Users hire products to do a job. The job — not the feature — is the correct unit of analysis for architecture decisions.
Thread: T10 (Abstraction) ← jobs abstract user intent away from system implementation → APIs and systems that model jobs are more durable than ones that model implementation
Core Idea: The same product category produces radically different architectures when the underlying jobs are different. Designing to the job produces systems that remain coherent as the product grows.
Tradeoff: AT6 (Generality vs Specialisation) — a job-oriented design adds scope and complexity upfront in exchange for architectural coherence as the product evolves
Failure Mode: FM12 (Split-Brain) — a system designed for one job becomes rigid when feature accretion changes the actual job being served without changing the architecture
Signal: When users consistently use a feature in a way that was not its intended purpose, the system was designed for the wrong job
Maps to: Book 0, Framework 1 (Mental Models)
Choose a product you use daily. What is the functional, emotional, and social job it does for you? How does the system’s architecture reflect each dimension?
Take an internal API in your current system. Does it expose what the system does, or what users want to accomplish? Rewrite the endpoints in job-oriented terms and compare the two designs.
The chapter argues that “write faster,” “write better over time,” and “not lose my work” are three different jobs that require three different architectures. Apply the same analysis to a system you work on. How many distinct jobs does it serve? Does the architecture reflect that number?
A team wants to add a feature to their product. Walk through how you would identify the job the feature serves, determine whether it is a new job or an extension of an existing one, and evaluate whether the current architecture can serve that job without structural changes.