Job to be Done

Origin & evolution

Clayton Christensen, the Harvard Business School professor behind disruptive innovation, popularised the idea in the early 2000s through the milkshake study. A fast-food chain had flat milkshake sales and had tried thicker, sweeter, fruitier versions with no effect. Christensen's team watched who actually bought them and found that roughly half sold before 8am, almost always to a solo commuter who wanted something to occupy a long, dull drive and last the whole journey. The milkshake's real competitors🥊CompetitorMarket IntelligenceA competing product or companyView reference → were a banana, a doughnut, and boredom. The story is told in Competing Against Luck (Christensen, Dillon, Duncan, Hall, 2016).

The lineage runs deeper than the milkshake. Anthony Ulwick named Outcome🏆OutcomeStrategyA desired business or user outcomeView reference →-Driven Innovation in 1999, patented the process, and introduced it to Christensen. Ulwick's school treats a job as a stable functional task☑️TaskProduct SpecificationA unit of work within a story or epicView reference → that customers measure through up to 150 quantified desired outcomes🌟Desired OutcomeUserWhat the user hopes to achieveView reference →, each phrased as a direction of improvement on a metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. This is the analytical, survey-friendly wing of the field.

A second school grew from Christensen's collaborator Bob Moesta, who built the Switch interview and the Four Forces of push, pull, anxiety, and habit. Here a job is the emotional and social progress someone seeks at a moment of struggle, reconstructed from the timeline of a real purchase. The phrase "jobs as progress" first appears in the Jobs to be Done Handbook (Spiek and Moesta, 2014). The two schools genuinely disagree. Ulwick has publicly rejected the progress framing as unmeasurable; the progress camp finds ODI's outcome lists mechanical. The honest position is that they answer different questions, and a serious team borrows from both.

How it works in practice

A B2B analytics team keeps shipping dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → features⭐FeatureProduct SpecificationA product capability or featureView reference → and keeps watching engagement stall. They run six Switch interviews with users who recently started and recently abandoned the product. A pattern surfaces: people open the tool the night before a board meeting, under pressure to explain one number that moved. The job is "walk into tomorrow's review able to defend the figure my CEO will ask about," and it is hired against a frantic Slack thread with the data team. Once the job is written that way, the roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → shifts from more charts to a single annotated "what changed and why" view. Engagement among the board-prep segment rises because the team finally built for the progress, not the feature list.

Job to be Done vs. its neighbours

• Need🫀NeedUserA user need, pain, desire, or constraintView reference → is a continuous state of lack ("I need to trust my numbers"). A job🔨JobUserJob To Be Done: what the user is trying to accomplish is a bounded act of progress in a circumstance ("get ready for tomorrow's board review"). A single job surfaces several needs, which is why the graph routes job_surfaces_needJobsurfacesNeedcausal from one to the other.
• Pain point is friction inside the current way of getting the job done. The pain ("the export breaks at month-end") only makes sense relative to the job it obstructs; it is a symptom⚠️SymptomEngineeringA symptom of a problemView reference →, the job is the target.
• Desired outcome, in Ulwick's precise sense, is a measurable success criterion the job is judged by ("minimise the time to verify a figure"). The job names the progress; the outcome makes it scoreable. The graph carries this as job_motivates_desired_outcomeJobmotivatesDesired Outcomecausal.
• Feature is one solution hired to do the job. Jobs outlive features, which is the whole point: the job stays fixed while the thing you build to serve it gets replaced.

In the graph

In the Unified Product Graph the job lives in the Users & Needs region as a hub, hanging off the persona🎭PersonaUserAn archetype representing a user segmentView reference → anchor through persona_pursues_jobPersonapursuesJobsemantic. From there it fans out: job_surfaces_needJobsurfacesNeedcausal, job_motivates_desired_outcomeJobmotivatesDesired Outcomecausal, and job_decomposes_into_job_stepJobdecomposes intoJob Stephierarchy for the sequence of smaller steps a job contains. Discovery work reaches back across the region boundary through opportunity_contextualises_jobOpportunitycontextualisesJobcross-domain, which is how a validated gap gets anchored to the progress it serves. The deprecated jtbd🔨JobUserJob To Be Done: what the user is trying to accomplish type folds into this canonical job🔨JobUserJob To Be Done: what the user is trying to accomplish, keeping the persona🎭PersonaUserAn archetype representing a user segmentView reference → who has the job and the job itself as separate, connectable entities rather than one blurred card.