TL;DR: Jobs to Be Done is a framework for understanding why customers buy or use a product, defined not by who the customer is or what features they want, but by the progress they are trying to make in a specific situation. It was developed by Clayton Christensen and Tony Ulwick and popularised by Bob Moesta's Switch Interview methodology. For product managers, JTBD is most useful during discovery, when the goal is understanding the real reason customers need a solution rather than the surface feature request they articulate. This guide covers the precise definition, the two schools of JTBD thinking, how to write a job statement, how to run a Switch Interview, and how JTBD connects to opportunity-solution mapping and AI-assisted discovery in 2026.

What is Jobs to Be Done?

Jobs to Be Done (JTBD) is a framework that defines customer needs as the progress a person is trying to make in a specific circumstance, rather than as a demographic characteristic, a product feature request, or a stated preference.

The core insight, drawn from Clayton Christensen's Harvard Business School research, is that customers do not buy products. They hire products to do a job. The job is the functional, emotional, or social progress the customer is trying to make. The product is merely the solution hired for that moment.

The famous formulation, attributed to Theodore Levitt but popularised through JTBD: "People don't want a quarter-inch drill. They want a quarter-inch hole." Taken further: they do not want the hole either. They want a shelf on the wall. They want their home to feel organised. The job is the unit of analysis, not the product, the feature, or the customer segment.

For product managers, this reframing has a specific practical implication: when a customer requests a feature, that request is not the job. It is a proposed solution to a job they have not yet articulated. The PM's discovery task is to uncover the underlying job, because the best solution to the job may not be the feature the customer described.

The two schools of JTBD thinking

JTBD is not a single unified framework. Two distinct interpretations evolved from the original work, and confusing them is common.

The Christensen school (demand-side jobs): Clayton Christensen, Bob Moesta, and the Harvard group focused on the circumstances and motivations that cause a customer to switch from one solution to another. Their method, the Switch Interview, probes the moment of purchase or adoption: what was happening in the customer's life that caused them to look for a new solution? What did they hire before? What pushed them to switch? This school focuses on the causal mechanism of demand, particularly useful for understanding new market opportunities and competitive displacement.

The Ulwick school (outcome-driven innovation): Tony Ulwick at Strategyn developed Outcome-Driven Innovation (ODI), which focuses on the jobs as a stable unit for market segmentation. He distinguishes the core functional job from the desired outcomes customers use to measure success at that job, then identifies which outcomes are underserved. This school is more systematic and quantitative, used to generate and score product opportunities from the desired outcome statements of a target job performer.

Both schools share the same foundational insight: focus on the job, not the product. They differ in research method, application, and the specific unit they analyse. For most product managers, the Christensen/Moesta approach is more practical for discovery research, while Ulwick's outcome mapping is more useful for systematic opportunity prioritisation.

This guide primarily covers the Christensen/Moesta approach for discovery, since it is the method most applicable to the continuous discovery practice that the majority of product teams are trying to build.

The three types of jobs

Every job has three dimensions. A complete JTBD analysis considers all three, because products that address only the functional dimension are more vulnerable to substitution than those that address all three.

Functional jobs: the practical task a customer is trying to accomplish. "Maintain visibility across all my active projects" is a functional job. "Process expense reports without chasing receipts" is a functional job. These are the jobs most naturally expressed in product requirements and the ones most easily captured in interviews.

Emotional jobs: how the customer wants to feel, or wants to avoid feeling, in the context of the job. "Feel confident presenting the roadmap to leadership" is an emotional job. "Avoid the anxiety of not knowing whether the team is on track" is an emotional job. Emotional jobs are rarely stated directly in interviews because customers often do not recognise them as needs. They show up in language about comfort, confidence, anxiety, and control.

Social jobs: how the customer wants to be perceived by others in the context of the job. "Be seen as the PM who ships features without firefighting" is a social job. "Demonstrate to my CEO that the product team makes data-driven decisions" is a social job. Social jobs are particularly important in B2B contexts where the user is accountable to peers, managers, or customers for the outcomes of their work.

Most feature requests that product managers receive address functional jobs. Products that also address the emotional and social jobs of their target users tend to produce stronger retention and higher NPS, because the product is embedded in the customer's identity and professional relationships, not just their workflow.

How to write a JTBD statement

A well-formed job statement has a specific structure that distinguishes it from a user story, a problem statement, or a feature request.

The Ulwick format:
[Direction] + [verb] + [object of the verb] + [contextual clarifier]

Example: Minimise the time it takes to identify which projects are at risk when preparing for a weekly leadership review.

The job statement is:

• Solution-agnostic: it describes the desired outcome, not the product

• Stable over time: it does not change when technology changes

• Measurable: a product can be evaluated against how well it fulfils the statement

• Expressed from the job performer's perspective, not the company's

The Moesta format:
When [situation], I want to [motivation], so I can [expected outcome].

Example: When I am preparing for a sprint planning session, I want to quickly understand which customer requests are creating the most friction, so I can make a defensible case for the priorities I recommend.

The Moesta format is closer to a user story but more focused on the situational trigger (when) and the underlying motivation (want) than the standard user story format, which often skips both.

What a job statement is NOT:

• "Users want a dark mode." That is a feature request.

• "Users want a better experience." That is an aspiration, not a job.

• "Users want us to be faster." That is a performance characteristic, not a job.

The test: if you can substitute a different product or solution and the job statement still makes sense, you have written a job statement. If it only makes sense with your specific product, you have written a feature requirement.

The Switch Interview: how to uncover the job

The Switch Interview, developed by Bob Moesta, is the most practical JTBD research method for product teams. It traces the full timeline of a purchase or adoption decision to uncover the causal forces that drove the customer to hire a new solution.

The interview covers four moments:

1. The first thought: When did the customer first think there might be a better way? What was happening? What triggered the awareness that the current solution was not good enough? This is the "passive looking" phase: the customer is not actively searching but has become aware of a gap.

2. The event: What happened that moved the customer from passive awareness to active searching? This is usually a specific incident that crossed a threshold. "My CPO asked me in a review meeting why we had spent six weeks on a feature that nobody used, and I realised I had no good answer."

3. The decision: How did the customer find and evaluate the new solution? What did they try? What nearly stopped them from switching? What gave them confidence to commit?

4. The first use: What happened the first time they used the new solution? Was it what they expected? What surprised them?

The four forces at work in every switch decision, according to Moesta's framework:

• Push: the frustration with the current situation that is motivating change ("our old tool required me to manually update four spreadsheets after every planning session")

• Pull: the attraction of the new solution ("the idea that it would just keep the roadmap updated automatically")

• Anxiety: the fear about the new solution ("what if the AI-generated priorities are wrong and my team builds the wrong thing")

• Habit: the comfort of the status quo ("we have always done it this way and everyone knows how the spreadsheet works")

A Switch Interview that maps all four forces produces a complete picture of the job: not just what the customer was trying to accomplish, but what convinced them the current solution was no longer good enough, and what gave them the confidence to hire something new.

Practical Switch Interview questions:

• Take me back to the day you first started thinking about finding a new solution for this. What was going on?

• What specifically happened that made you start actively looking?

• What were you using before? What did that solution do well?

• What made you feel like the old solution was no longer good enough?

• How did you find our product? What made you decide to try it?

• What nearly stopped you from switching?

• What did the first week using it actually feel like?

JTBD in practice: examples from B2B product teams

Example 1: Product management platform

Feature request received: "Can you add a timeline view to the roadmap?"

Surface-level response: build a Gantt chart.

JTBD investigation via Switch Interview reveals: the customer's job is "present a convincing, credible roadmap to the engineering lead in the monthly planning meeting so that engineering commits to the right priorities without negotiating everything down." The timeline view was proposed as a solution because they had seen Gantt charts used in these meetings. But the actual anxiety was about credibility and negotiating power, not timeline visualisation. The product decision changes: the best solution might be timeline view plus the ability to show customer evidence attached to each item, plus a comparison view showing what was dropped and why, all of which address the credibility and defensibility need more directly than a Gantt chart alone.

Example 2: Customer analytics tool

Feature request received: "We need to be able to filter by company size."

Surface-level response: add a company size filter.

JTBD investigation reveals: the customer's job is "identify which accounts are at risk of churning before the renewal conversation so I can prioritise outreach." Company size filtering was the proposed solution because the customer believed their at-risk accounts were correlated with company size. But the actual job is churn risk identification. The better solution might be a churn risk score based on engagement patterns, with an alert system, rather than a filter that requires the PM to manually check each account.

In both cases, the feature request was a reasonable but suboptimal solution to the underlying job. JTBD research surfaces the job and opens the solution space.

How JTBD connects to the Opportunity-Solution Tree

Teresa Torres's Opportunity-Solution Tree (OST) is the most widely adopted framework for continuous discovery. It has a direct structural connection to JTBD that is underexplained in most OST guides.

The opportunity layer of the OST is where JTBD lives. An opportunity, in Teresa Torres's definition, is "an unmet customer need, pain point, or desire." Translated into JTBD language: an opportunity is an underserved job. The customer has a job they are trying to get done, and their current solution is not doing it well enough.

A job statement derived from JTBD research is the most rigorous way to articulate an opportunity. "Users want better filtering" is a weak opportunity statement. "Engineering managers want to identify blocked tasks across all their active projects before their Monday morning standup, so they can address blockers before the team hits them" is a job statement that also serves as a well-defined opportunity.

The solution layer of the OST is where specific products, features, or approaches are proposed to address the opportunity. The job statement anchors the solution space: any proposed solution should be evaluated against how well it enables the job to be done, not just whether it satisfies the feature request.

The assumption tests that form the bottom of the OST map directly to the four forces in the Switch Interview: push (does the customer's current solution have strong enough frustration to motivate switching?), pull (does the proposed solution address the job compellingly?), anxiety (what concerns would prevent adoption?), and habit (how embedded is the current solution?).

When JTBD research feeds the OST, the product team is working with evidence rather than hypotheses at the opportunity layer. The solution comparison and assumption testing become more precisely targeted because the job is clearly defined.

Squad AI implements this connection directly. When its Insights agent surfaces opportunities from connected customer signal, those opportunities are derived from the recurring themes in what customers say, do, and feel across support tickets, interviews, and feedback channels. The Strategy agent then maps competing solutions against each opportunity using Tree-of-Thought reasoning, producing the same functional output as an OST built from JTBD research, with the synthesis work automated rather than manual.

How AI is changing JTBD research in 2026

The traditional Switch Interview is time-intensive: scheduling, running, and synthesising one-hour interviews for the five to ten participants needed to identify a clear JTBD pattern typically takes two to four weeks of a PM's time.

AI tools have changed this in two meaningful ways.

AI-moderated async interviews compress the timeline from weeks to days. Tools like Perspective AI run Switch Interview protocols asynchronously: a customer receives a conversational link, the AI moderator conducts the interview (asking follow-up questions when answers are vague), and the PM receives a structured transcript. Twenty Switch Interviews can run simultaneously over three days rather than sequentially over three weeks.

AI synthesis across existing signal surfaces JTBD patterns from data already in the product stack. Support tickets, Gong call recordings, NPS verbatims, and Slack messages all contain customers describing their jobs in their own language. AI synthesis tools can identify recurring job statements across hundreds of data points, giving PMs a starting hypothesis about the jobs their customers are trying to accomplish before any primary research begins.

The combination is powerful: AI synthesis from existing data generates the hypothesis, AI-moderated Switch Interviews validate and deepen it, and the output is a well-defined job statement ready to anchor the opportunity layer of the OST.

The parts of JTBD research that AI cannot replace are the judgment calls: deciding which job is most strategically important to serve, evaluating whether the proposed solution space is genuinely novel or just a rearrangement of existing approaches, and determining whether the job is stable enough to build a product strategy around. Those remain human decisions.

Frequently asked questions

What is Jobs to Be Done (JTBD)?
Jobs to Be Done is a framework for understanding customer needs as the progress a person is trying to make in a specific situation, rather than as demographic characteristics or feature preferences. Customers "hire" products to do a job. The job is the functional, emotional, or social progress they are seeking. Understanding the job rather than the feature request opens a wider and more accurate solution space.

Who invented Jobs to Be Done?
JTBD was developed from research by Clayton Christensen at Harvard Business School, popularised through his book The Innovator's Solution (2003) and the milkshake marketing example in Competing Against Luck (2016, with Taddy Hall, Karen Dillon, and David Duncan). Tony Ulwick at Strategyn developed a parallel, more systematic version called Outcome-Driven Innovation, first published in 2002. Bob Moesta, who worked with Christensen, developed the Switch Interview methodology and founded the ReWired Group to train practitioners.

What is the difference between JTBD and user stories?
A user story describes what a user wants to do within a product (As an engineering manager, I want to filter tasks by status so I can see what is blocked). A JTBD statement describes the underlying progress the user is trying to make in their life or work, independent of any specific product (When preparing for a leadership review, minimise the time it takes to identify which projects are at risk). User stories define a feature. JTBD statements define the need the feature should address. A good feature requirement is a solution to a well-defined job.

What is a Switch Interview?
A Switch Interview is a JTBD research technique developed by Bob Moesta that traces the full timeline of a customer's decision to adopt a new solution. It explores the moment of first awareness (when did they first think there might be a better way?), the triggering event (what specifically caused active searching?), the decision process (how did they evaluate and choose?), and early use (what happened when they first used the new solution?). The goal is to map the four forces: push (frustration with the current situation), pull (attraction to the new solution), anxiety (fears about switching), and habit (inertia of the current approach).

How many Switch Interviews do I need?
Most practitioners find that four to eight Switch Interviews are enough to identify a clear pattern for a well-defined job. Clayton Christensen cited the rule of thumb that patterns in JTBD research typically emerge within five interviews. The caveat is that the interviews must target customers who have recently made a relevant switch decision: they recently adopted your product, recently churned, or recently changed how they solve the problem. Customers who have been stable for years have weaker recall of the decision context.

How is JTBD different from user research?
User research is a broad category of methods for understanding users, including usability testing, ethnographic observation, diary studies, and surveys. JTBD is a specific theoretical framework for defining customer needs, which can be researched through several methods. The Switch Interview is the most distinctively JTBD method, but JTBD-informed researchers use observational studies, diary studies, and even quantitative surveys structured around job statements. JTBD is more a lens than a method: it shapes what you look for in research rather than the specific technique you use.

How does JTBD connect to the Opportunity-Solution Tree?
An opportunity in Teresa Torres's Opportunity-Solution Tree is an unmet customer need, pain point, or desire. In JTBD terms, an opportunity is an underserved job. A JTBD job statement is the most precise way to articulate an opportunity because it is solution-agnostic, stable over time, and expressed in customer language. The solution layer of the OST maps to the proposed approaches for enabling the job to be done. The assumption tests map to the four forces: does the customer's frustration with the current solution (push) motivate switching? Does the proposed solution address the job compellingly (pull)? What anxieties might prevent adoption? How strong is the habit around the existing solution?

Can AI help with JTBD research?
Yes, in two ways. AI-moderated interview tools like Perspective AI can run Switch Interview protocols asynchronously, allowing twenty or more interviews to run in parallel rather than sequentially, compressing research timelines from weeks to days. AI synthesis tools can identify JTBD-relevant patterns across existing data sources (support tickets, call recordings, feedback channels), generating starting hypotheses about which jobs customers are trying to accomplish before primary research begins. The judgment calls about which job to prioritise and whether a proposed solution genuinely addresses it remain human.

Sources: Clayton Christensen, Taddy Hall, Karen Dillon, David Duncan, Competing Against Luck (2016); Bob Moesta and Greg Engle, Demand-Side Sales (2020); Tony Ulwick, Jobs to Be Done: Theory to Practice (2016); Jim Kalbach, The Jobs to Be Done Playbook (2020); GitLab JTBD Handbook. Last updated: August 2026 · meetsquad.ai