What is the Jobs-to-Be-Done (JTBD) Framework?

Jobs-to-Be-Done is a framework for understanding what customers really aim to achieve when they "hire" a product or service. Rather than focusing on product features or user demographics, JTBD looks at the underlying goal or "job" the user wants to accomplish - the progress the customer is trying to make in a given circumstance[1]. In other words, when someone buys or uses a product, they are hiring it to get a job done; if it performs well, they’ll "hire" it again, and if not, they’ll "fire" it and seek an alternative[2]. JTBD frames these goals at a high level, including the functional outcome the user wants and the broader context around it (why it matters, and in what situation). For example, "Users don’t hire a drill because they want a drill - they hire it to get a hole in the wall." Similarly, "Customers buying high-tech skateboards with fancy parts really just want to land a kickflip"[3]. In a product context, a user might not "hire" Spotify just to access a music library, but rather to "easily enjoy the music they love during daily life"[4] - the music service is simply a means to that end goal. By articulating the true job-to-be-done (the progress the user seeks), product teams can innovate solutions that genuinely help users accomplish their goals[5].

Key Elements of a Well-Formed JTBD

A well-formed JTBD definition typically has three dimensions: a functional goal, and accompanying emotional and social aspects. The functional job is the core task or outcome the user is trying to accomplish - what they want to get done, independent of any specific solution[6][7]. For example, a functional job might be "get to a destination on time" or "pass on life lessons to my children"[8][9]. In addition, JTBD analysis considers the emotional and social components tied to that job[10]. The emotional aspect is how the user wants to feel while doing the job or after it’s done (e.g. feeling in control, confident, relieved, etc.), and the social aspect is how they want to be perceived by others (e.g. appear responsible or innovative)[11]. For instance, when parents hire a solution to "pass on life lessons" (functional job), they may also want to feel like good caregivers and appear as good parents to peers (emotional/social jobs)[12].

In practice, researchers often capture JTBD insights in a concise statement or "job story." A common format is: "When [situation], I want to [job], so I can [desired outcome]", sometimes adding "...without [pain point]"[13]. This structure ensures we include the context (the when/why circumstance), the user’s true objective (the what they want to achieve), and the outcome or benefit they seek (the why it matters, often implicitly addressing an emotional gain or pain point). For example, a JTBD statement for a research recruiting tool was: "When I’m recruiting participants for a study, I want to automate screening, scheduling, and reminders so I can move participants through the process quickly without the time-suck of doing it manually."[14]. This single sentence encapsulates the functional job ("automate screening… scheduling…"), the context ("when recruiting for a study"), the desired outcome ("quickly move participants through") and the pain point to eliminate ("enormous time-suck" of the manual process). A well-formed JTBD statement is solution-agnostic (it doesn’t assume a particular product or feature) and focuses on the user’s need in their own terms, including relevant emotional/social context. It should be specific enough to imply clear criteria for success, but not so narrow that it just describes using a certain solution or a fleeting trend[8][15].

Good vs. Weak JTBD Statements

Not all JTBD statements are created equal. Strong JTBD statements clearly articulate the true goal of the user in a solution-agnostic way, whereas weak statements might accidentally focus on a specific solution, technology, or vague action without a clear goal. Here are some guidelines and examples:

Focus on outcome, not the solution technology: A good JTBD phrasing centers on the outcome the user wants, whereas a poor one might mention a specific tool or format. For example, "Get to a destination on time" is a strong job-to-be-done description - it states the objective in general terms[8]. In contrast, "Play MP3s" would be a weak attempt at a JTBD, because playing an MP3 describes using a specific file format/technology rather than the underlying goal (why the user wants to play music)[8]. The first focuses on the why (arrive on time), while the second focuses on a how (using MP3, which is just one solution). Users don’t inherently desire "MP3 playing" - what they really want might be "enjoy music on-the-go" or "have portable access to songs". Always phrase the job in terms of the problem or goal, not your product’s features.

Use a clear action verb + object (specific goal): The best JTBD definitions use a verb-object structure that succinctly captures what the user is trying to accomplish[16]. For example, "find a recipe for dinner" or "coordinate team schedules" are clear and actionable. Avoid overly broad verbs with no object (e.g. just "communicate" or "manage") - these are too vague to guide product decisions[15]. If you find a job phrased as "manage X" or "communicate", ask "manage or communicate what and to what end?" A bad example would be "communicate with clients" - does the client want to learn something, feel reassured, share information? Instead, a well-defined job might be "deliver project updates to clients clearly" (which has a clearer end goal: clients being up-to-date and confident) - this provides direction on what "communicate" really entails.

Keep it solution-agnostic and stable: A weak JTBD statement often sneaks in a specific solution or ephemeral trend, which limits thinking. For instance, "use a mobile app to track fitness" is too specific about the solution (mobile app). A stronger formulation would be "monitor and improve my fitness progress" - it captures the job to be done without implying how the user will do it. The job should hold true over time even as solutions evolve[17][6]. If your statement name-drops your product or a current technology, consider abstracting it. (E.g., instead of "set up a CRM" - which is solution-centric - the real job might be "keep track of customer relationships" or "maximize my outreach effectiveness"). The latter expresses what the user needs (and why) in a form that could inspire many possible solutions.

Incorporate the context or criteria if needed: A strong JTBD can sometimes include a clarifier to specify the context or what "done well" looks like. For example, "purchase a house within budget and in the right neighborhood" adds criteria that matter to the user. However, be cautious: don’t overload the job statement itself with every detail; additional needs can be captured as outcomes or criteria separately. The main statement should stay clear and digestible (you can list detailed outcome criteria separately as we do in Outcome-Driven Innovation). A telltale sign of a weak statement is if it reads like a long run-on or includes conjunctions like "and/or" trying to mash multiple jobs into one; it’s okay (even preferred) to break those into separate job statements if they’re distinct goals[18][19].

Examples:

Good JTBD: "Getting to a destination on time." - (Solution-agnostic, outcome-focused: it captures the real goal of travelers, irrespective of using a map app, train, or any method)[8].
Weak JTBD: "Use GPS navigation to drive somewhere." - (Solution-specific and not the core goal - the real job isn’t "use GPS", it’s arriving on time or without getting lost. The GPS is just a tool.)

Good JTBD: "Coordinate group travel plans for a vacation." - (Clear objective with an action and object, implying multiple people’s inputs need alignment.)
Weak JTBD: "Plan a trip using our app." - (Mentions a specific app (solution) and doesn’t clarify what aspect of "planning" is the goal. Is it finding a destination, creating an itinerary, booking flights? It’s too broad and tied to the product.)

Good JTBD: "Optimize cash flow for my small business." - (Focuses on the end goal: keeping finances healthy, with a strong verb "optimize" and object "cash flow")[20][21].
Weak JTBD: "Manage customers with a CRM." - (Includes a solution "CRM" and a vague verb "manage". A better articulation might be "retain and grow customer relationships," which gets to why one would use a CRM in the first place.)

In summary, good JTBD statements are user-centric, outcome-oriented, specific, and enduring, whereas poor ones are solution-led, too general, or reflective of an ephemeral tactic rather than the fundamental job. By ensuring the JTBD is well-crafted, teams set a strong foundation to ideate and prioritize features truly aligned with user needs.

JTBD vs. Latent Needs Assessment: Overlaps & Differences

Both JTBD analysis and general latent needs assessment share a common aim: to uncover the deeper, unspoken needs and motivations of users that traditional research might miss. In traditional user research, latent needs refer to the unmet or unarticulated needs users have - things customers desire or problems they have but don’t explicitly express (often because they take them for granted or can’t easily verbalize them). JTBD and latent needs assessment overlap in that both strive to look past surface-level wants (like feature requests) and understand why users behave as they do, getting at the root causes or goals. In practice, a researcher doing a latent needs study might use ethnography, interviews, or observations to infer what users really need, which is quite similar to a JTBD researcher probing "what the user is really trying to accomplish." In fact, good JTBD interviews inherently reveal latent, unmet needs by focusing on the struggles and goals that customers themselves may not immediately articulate[22].

However, JTBD offers a more structured lens for capturing these insights compared to a general latent needs approach. In a typical latent needs assessment, findings might be described as broad insights or user pain points (e.g. "commuters need a way to eat breakfast on the go"). JTBD would take that insight and frame it as a job statement or outcome, like "sustain myself with a convenient breakfast during my morning commute." The difference lies in JTBD’s rigor and vocabulary for describing needs. For example, Jobs Theory defines needs in a very specific way - as the metrics customers use to measure success when getting a job done[23]. These are often phrased as desired outcomes (e.g. "minimize the time to ", "increase the likelihood of "). By defining needs in this structured, measurable form, JTBD makes latent needs explicit and actionable, rather than leaving them as vague or "unknowable" sentiments[23]. In other words, JTBD doesn’t accept that needs must remain fuzzy - it provides tools to articulate them precisely.

Another distinction is scope: JTBD centers on the "job" as the unit of analysis, not the product or persona[24]. This means when we explore latent needs through JTBD, we anchor them to specific circumstances and goals. For instance, rather than generically saying "customers secretly want to feel in control," a JTBD approach would tie that to a job context: "When managing personal finances (job), customers need to feel in control of their spending (emotional job)." The latent emotional need ("feel in control") is thus captured as part of the job story, ensuring it’s considered in design. Traditional latent needs research certainly can surface the same insight, but it might be reported as a standalone finding ("Users feel out of control of spending, which is a pain point"). The JTBD method integrates it into the job framework so that functional and emotional needs are considered together.

Overlap: Both approaches rely heavily on qualitative research (interviews, observation) to uncover truths the customer isn’t directly telling us. Both value context - understanding the user’s environment, habits, and struggles. In fact, many UX researchers find that JTBD is complementary to persona and empathy work, as all aim for a deep understanding of user problems and context[25][26].

Differences: JTBD provides a consistent format to describe those needs (jobs, outcomes, forces, etc.), which helps in mapping and prioritizing them. Latent needs assessment might not have a single standardized format - it’s more of a broad goal of finding hidden needs, often relying on the researcher’s interpretation to present them. Also, JTBD explicitly pushes teams to ignore current solutions and markets when thinking about needs ("jobs are solution-agnostic and stable over time" is a core tenet)[17]. This can lead to more innovative, cross-category insights, whereas latent needs research could sometimes stay within the confines of the current product domain unless deliberately looking beyond. For example, a latent need might be identified like "people want a faster horse" (if we asked 1900s carriage users). A JTBD reframing would say "job: travel from A to B faster with minimal effort" - which invites solutions like cars, not just better horses. Thus, JTBD reframes needs in a way that broadens the solution space and highlights opportunities that a narrower needs assessment might miss.

In summary, JTBD and latent needs assessment both seek the "unknown truths" about customers, but JTBD gives a structured framework to articulate and leverage those truths. One could say JTBD is a particular way of doing latent needs discovery - one that "packages" the insights into jobs, outcomes, and narratives that can be directly used for innovation. Many organizations find value in using them together: first uncover latent needs through immersive research, then frame those needs as jobs-to-be-done to systematically brainstorm and evaluate solutions.

JTBD Research Frameworks

When applying JTBD in practice, UX and product researchers have developed several frameworks, templates, and analytical tools to gather and present insights. These help in mapping out the "job" and its associated needs, and in communicating the findings to stakeholders. Below, we outline some of the key JTBD-related research outputs and frameworks, along with their uses:

The Four Forces of Progress

One popular JTBD tool for analysis is the "Four Forces of Progress" model. This framework, originally formulated by Clayton Christensen’s team and Bob Moesta, visualizes the pushes and pulls that influence a customer’s decision to switch to a new solution (or to not switch)[27][28]. The idea is that when a person considers adopting a new product (making "progress"), there are competing forces at play - some encourage the change and others create resistance. The four forces are typically described as two pros and two cons:

Push of the Situation: The frustrations or problems with the current solution that push the user to seek something better[28]. Essentially, it’s the discomfort or "struggle" that makes the status quo unsustainable (e.g. "What I’m doing now isn’t working…"). For example, "My current camera is too bulky and inconvenient" could push a user to consider a new camera[29].

Pull of the New Solution: The attractive qualities of a new solution that pull the user toward it[28]. This is the allure or promise of improvement (e.g. "This new option sounds much better because…"). For instance, "A digital camera would make it easier to share photos and never deal with film" represents a pull towards a modern solution[30].

Anxiety of the New Solution: The fears, uncertainties, or anxieties about switching that act as friction against change[31]. Users worry about what could go wrong with the new solution ("What if this new product doesn’t work out?"). Example: "There are so many features on this new camera - what if I can’t learn them and I waste my money?"[32].

Habit (Inertia) of the Present: The comfort and attachment to the current solution that also blocks change[31]. People are creatures of habit; even an imperfect status quo can feel familiar and safe. For example, "I’ve been using my old camera for years; I’m emotionally attached and used to its quirks." This inertia (sometimes called "allegiance to the status quo") can make us reluctant to switch[33][34].

If the Push + Pull forces outweigh Anxiety + Habit, the user is likely to switch to a new product; if not, they remain with their current solution[35]. Researchers map these forces by conducting in-depth switch interviews (more on this below) to capture what was going through the customer’s mind during the buying decision[36]. The output might be a forces diagram or simply a list of the identified pushes, pulls, fears, and habits for a given JTBD. This is extremely useful for product strategy: it highlights not only what would make someone adopt your product (pushes to amplify, pulls to emphasize in marketing) but also what obstacles you must overcome (habits to break, anxieties to alleviate). In essence, the Four Forces of Progress provide a holistic view of the customer’s decision-making context - beyond just features, it captures emotional drivers and barriers to innovation[37][38].

Struggle-Based Journey Mapping (Switch Timeline)

JTBD research often involves digging into the timeline of a customer’s "struggle" and eventual switch to a new solution. This is sometimes called a switch journey mapping or struggle-based journey mapping. The idea, pioneered by Bob Moesta and others, is to interview customers about the series of events and triggers that led them from first recognizing a need, through exploring options, to finally choosing a product. The emphasis is on the struggling moments - when and why did their current solution fall short, and how did they navigate the path to something new?

A common way to do this is by using a timeline framework during interviews. For example, JTBD practitioners often break the journey into stages such as: First Thought -> Passive Looking -> Active Research -> Deciding -> Purchase -> Post-Purchase (Consumption and Reflection)[39][40]. During an interview, the researcher will walk through each stage in detail:

First thought: When did the user first realize they had a problem or goal? What specific incident or thought "sparked" the desire for change[41]? (e.g. "I spilled coffee on my old laptop and thought, I really need a better travel mug" - a triggering event or thought).
Passive looking: After the first thought, was there a period of casually noticing options or just living with the problem? What did the user do next, even before actively seeking a solution[42]?
Active looking: What made them start seriously researching or shopping for alternatives? Where did they search, what options did they consider, and who or what influenced them at this stage[43]?
Deciding: How did they compare options and finally make the decision? What criteria mattered (price, features, recommendations)? Did anything almost stop them or change their mind[44]?
Purchase: Why did they buy when they did - was there a specific event or deadline that pushed them over the edge? How did the transaction happen[40]?
Consumption & satisfaction: Once they started using the new solution, how did it go? Did it solve the struggle? What frustrations remain or what do they love? Are they satisfied or are there new "jobs" arising from it[45][46]?

Throughout this journey mapping, the researcher is paying special attention to the struggle at the beginning and any lingering struggles at the end. The "struggling moment" is often the seed of innovation - that’s where the user’s need for progress was strong enough to drive them to seek a new solution[47]. For example, in a switch interview a user might say: "I was using Product X, but it frustrated me that it took so long to do Y". That frustration is the push that started their journey[48]. Mapping it out, along with context (who was involved, where they were, what else was happening in their life), gives rich insight into the circumstances of the job.

Such struggle-based journey maps are powerful for pinpointing opportunities. They show pain points and obstacles in the current user experience (which your solution could address) and reveal the moments that matter most in the decision process[49][50]. For instance, if multiple users’ timelines show that "comparing options was overwhelming" during active looking, that indicates a job step that is ripe for improvement (maybe a simpler comparison feature or decision aid could be valuable). Likewise, if many hesitate at the deciding stage due to anxiety about cost, that’s a clue to address pricing or offer reassurance (one of those anxiety forces). By visualizing the journey from the user’s perspective, including emotional highs and lows, teams can empathize with where users struggle and ensure their product and messaging directly speak to those moments.

JTBD Canvas (Visual Template)

Example of a JTBD Canvas (from GitLab’s JTBD playbook) capturing the various elements of a job on one page: the Main Job, the Job Performer, related jobs, job steps (mapped as a timeline of stages), desired outcomes (needs statements), and emotional/social aspects.

To organize and communicate JTBD research, many teams use a JTBD Canvas - a one-page visual template that compiles all key insights about a particular job. This canvas is similar in spirit to a business model canvas or lean canvas, but focused on the job-to-be-done. It typically includes sections such as:

Job Performer: Who has this job? (e.g. "Busy parent", "Data analyst") - essentially defining for whom we’re solving, often abstracted as a role rather than a persona name[51].
Main Job: A succinct statement of the core functional job-to-be-done we’re focusing on (action + object + context)[52][53]. For example: "Acquire a new home" or "Analyze website traffic trends." This is the anchor for the canvas.
Related Jobs: Other goals or jobs that often coincide or are carried out by the same person in that domain[54][55]. For instance, alongside "acquire a new home" the person might also need to "sell current home" or "move belongings" - these are related jobs that provide context but are distinct.
Job Steps (Job Map): The high-level steps the user goes through to complete the main job[56][57]. This is essentially a mini journey map or job map - capturing the generic process of the job. For "acquire a new home," steps might be "decide where to look -> search listings -> tour homes -> secure financing -> purchase home," etc. Each step is phrased as what the user needs to do (solution-agnostic) and can be further broken into sub-steps or pain points if needed.
Outcomes (Needs Statements): A list of the user’s key success criteria and metrics for the job - i.e. what "done well" means[58][59]. These are those "desired outcomes" often phrased with a direction and metric (e.g. "Minimize the time it takes to ", "Increase the likelihood of ") as discussed. In a canvas, you might see sticky-note style items like "Minimize the time to find a suitable home within budget" or "Increase confidence that I’ve chosen the best option." Capturing these helps ensure the team knows what to optimize for.
Pain Points & Obstacles: Many canvases (or especially a related artifact called the Jobs Atlas, below) will include a section for current pain points, obstacles, or "constraints" that make the job hard[60]. This often comes from research: e.g. "Pain: hard to coordinate with spouse on choices," "Obstacle: mortgage approval process is confusing." These highlight what needs are unmet with current solutions.
Emotional/Social Jobs: A space to list how the user wants to feel or be perceived while doing the job[61][62]. For example: "Feel in control of the process" (emotional) or "Appear as a competent investor to my family" (social) for a home-buying job. Including these ensures designs consider not just functional outcomes but also emotional fulfillment.
Contextual factors / Job Drivers: Sometimes canvases include things like triggers (what sparks the job) or situational factors that influence how the job is done. For instance, "Job driver: need to relocate for work" might be noted if that’s a common trigger to buying a new home.

A JTBD Canvas serves as a strategic blueprint - it lays out on one page everything the team should keep in mind about the job. It’s very useful for workshops and alignment because it uses simple language and visual organization. The example canvas above (from GitLab’s handbook) shows sticky notes under each section, representing distilled research findings (like key outcomes or pain points). By looking at a filled canvas, a team can quickly grasp who the user is, what they’re trying to do, what defines success, and where the friction lies. This drives brainstorming ("how might we help achieve these outcomes?") and ensures that feature ideas are tied back to real user jobs and needs, not just random ideas. Many companies have their own version of a JTBD canvas or JTBD template - for instance, there are "JTBD cheat sheets" and canvas variations published by Strategyn, Intercom, and others[63][64]. The specifics vary, but the core idea is to have a concise visual summary of the job that is informed by research and can be shared easily.

Jobs Atlas (Comprehensive JTBD Mapping)

The Jobs Atlas takes the canvas concept a step further. It is a term used by some practitioners (notably at New Markets Advisors and in the UX community via tools like Dovetail) to describe a comprehensive map of JTBD research insights, showing how various pieces connect. Think of it as combining multiple canvases or perspectives into one unified view - truly an "atlas" of the job landscape.

According to UX researcher Nikki Anderson, "the job atlas is a way to bring together different components of JTBD research and show their relationship, helping colleagues act on the insights."[65]. In a jobs atlas, you’ll typically see four quadrants or sections corresponding to the major elements of the research:

Needs & Motivations - documenting the key outcomes and motivations the users have (the "why" behind the job)[60]. This corresponds to those desired outcomes or success metrics we’ve discussed.
Behaviors & Tasks - outlining what users do to accomplish the job (the "how/what" they currently do, i.e. the steps or workflows)[60]. This captures the process, possibly similar to a job map or journey.
Pain Points & Obstacles - highlighting where users struggle, encounter friction, or what barriers prevent them from switching[49][66]. These could be points in the journey or external constraints (like "lack of time," "corporate policy," etc. depending on context).
Ideal Outcomes - describing what a "perfect" solution would deliver, or what success looks like if all needs were met[67]. This might overlap with needs statements, but often paints the picture of a resolved struggle (e.g. "I can book a trip in minutes with full confidence in my choice").

By plotting these out, the job atlas makes it visually clear where certain behaviors lead to certain pain points or where certain needs are not met[49]. It’s essentially a synthesized deliverable of your JTBD study. A real-world example: imagine a team studied the job "Book a leisure trip" (as in the Dovetail blog scenario) and found several sub-jobs (search for trip, compare options, coordinate with friends, etc.), a bunch of needs ("minimize time to compare prices", "reduce risk of a bad choice", etc.), and pain points ("overwhelmed by too many travel sites", "hard to agree on plans with friends"). The jobs atlas would layout these findings in one place so you can draw connections - e.g., the pain point "overwhelmed by options" ties to the need "maximize ability to compare different aspects easily"[68]. This could spark design ideas like building a comparison dashboard or summary feature.

New Markets Advisors describes their Jobs Atlas as focusing on "eight key elements of customer decision-making" for a job, mapping out priorities, drivers, current approaches, pain points, success criteria, obstacles, value, and competition[69]. In other words, they gather everything from why a job is important (drivers), how people currently get it done (approaches & hacks), what’s frustrating (pains/obstacles), what outcomes define success, and even what competing solutions exist. The result is a very rich diagram or document that gives a 360° view of the job space.

For a UX/product researcher, a jobs atlas is an excellent storytelling tool. It helps convey the research findings to stakeholders in a structured way: you can literally walk them through "Here’s the job and why users pursue it; here’s what they currently do and where it sucks; here’s what they wish for and value; and here’s how our product (or competitors) fit in." By seeing it all together, teams can spot gaps (areas of unmet needs), align on which unmet needs to tackle first, and ensure any solution addresses not just functional tasks but also the emotional and social side. It turns JTBD from an abstract idea into a tangible map for innovation.

Outcome-Driven Innovation (ODI) Formats (Job Maps & Outcome Statements)

Outcome-Driven Innovation (ODI) is a methodology developed by Tony Ulwick (of Strategyn) that operationalizes JTBD theory with quantitative rigor. In ODI, the focus is on identifying all the "jobs" and "outcomes" a customer has in a given domain, then prioritizing opportunities by finding which outcomes are least well-served. Two key formats from ODI often used in JTBD work are Job Maps and Desired Outcome Statements:

Job Map: This is a step-by-step breakdown of the job-to-be-done into its constituent process steps, abstracted from any specific solution[70][71]. Tony Ulwick found that many jobs can be described in a generic sequence of steps (often eight steps in their model). These steps cover the lifecycle of a job, from the planning stage to execution and conclusion. For example, a generic job map often includes steps like Define (the goals or what you’re trying to achieve), Locate (gather inputs/resources), Prepare (set up everything to start), Execute (do the main task), Monitor (check if it’s going well), Modify (make adjustments), and Conclude (finish or wrap up)[72][73].

An example of a generic Job Map structure (per ODI methodology): jobs are broken into steps such as Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, and Conclude[72]. This provides a scaffold for analyzing where in the process users have unmet needs.

By mapping a specific job (say, "Cooking a meal") onto those steps, you can identify where things go wrong or could be improved at each step. The value of a job map is that it forces you to consider the entire process of the user’s job, not just the part where your product is involved. It also makes it easier to spot opportunities: if "Confirm" (step 4) is a challenge for users (e.g. verifying all ingredients are ready before cooking), that might be a chance to innovate (maybe a smart checklist or something). A job map is a qualitative output that guides ideation and ensures completeness in understanding the job scope.

Desired Outcome Statements: These are carefully worded need statements capturing how customers measure success in each step of the job. ODI outcome statements have a specific syntax: "Direction of improvement + metric + object + context"[58]. For example: "Minimize the time it takes to book a round-trip flight", or "Increase the likelihood of choosing the best travel option for my budget"[68]. Each statement targets a very specific aspect of the job. The power of this format is that it turns nebulous needs into concrete, testable statements. In an ODI project, researchers might gather 50-150 outcome statements from interviews (covering all steps of the job)[74]. They then survey customers to rate each outcome on Importance and Satisfaction - essentially asking how important that outcome is and how satisfied they are with current solutions on that outcome. The resulting data identifies unmet needs quantitatively (high importance, low satisfaction gaps)[75][76]. This is beyond standard UX practice, edging into product strategy and innovation process, but it’s a core part of JTBD theory in practice.

In summary, ODI formats like job maps and outcome statements provide a structured way to analyze qualitative insights and prioritize them. Even if a team doesn’t do a full quantitative ODI study, just writing needs in that outcome format is helpful. For instance, instead of saying "Users need a faster way to compare options," an outcome statement would be "Minimize the number of steps required to compare multiple options side by side." This clarity can guide design requirements directly.

By applying these ODI techniques, teams treat customer needs as design targets. You can systematically ideate features to address the biggest unmet outcomes, and later test if the new solution indeed improves those metrics. It’s a way of connecting the dots from deep user research (JTBD interviews) to product strategy and roadmap decisions. Many product teams who embrace JTBD end up incorporating some ODI principles, because it ensures the voice of the customer (in terms of jobs and outcomes) is driving innovation rather than gut feel. As a practical output, one might see an "Opportunity Matrix" - a chart of all outcome statements plotted by opportunity score, or simply a list of top unmet needs that the team will focus on[75][76]. This kind of rigor is what makes JTBD very appealing in corporate innovation: it brings predictability and focus by clearly showing which customer "jobs to be done" are most ripe for improvement.

Jobs-to-be-Done framework provides product and UX researchers with a powerful way to understand and articulate user needs. By focusing on the jobs people are trying to accomplish - and using the above tools like Forces diagrams, journey maps of struggle, canvases/atlases, and outcome-driven analysis - teams can generate real-world insights and templates that drive design and strategy.

The JTBD approach ensures that we design for the outcomes and experiences users truly value (both functional and emotional)[77][26]. Whether it’s through a neatly crafted JTBD statement, a visual jobs canvas, or a quantitative unmet needs analysis, the end result is the same: a deeper empathy for what users really need and a clearer direction for innovation that can reliably meet those needs. This alignment of product strategy with the actual "jobs" of users is why companies from Microsoft to Home Depot have cited JTBD as key to delivering customer value[78] - it keeps the team’s focus on solving the right problems, in the right way, for the right reasons. By applying JTBD in practice, product and UX professionals can uncover latent opportunities, create more user-centered products, and ultimately help users make the progress they’re looking for in their lives. [79][80]

Sources:

Christensen, C. M., et al. "Know Your Customers’ ‘Jobs to Be Done.’" Harvard Business Review, 2016[1][2].
User Interviews - UX Research Field Guide: "Jobs to Be Done (JTBD) in UX Research"[5][13][79].
Klement, A. - JTBD.info blog. "Good & Bad JTBD Statements" (via thrv)[8][20].
Ulwick, T. - Strategyn: "Jobs-to-be-Done Playbook" and ODI resources[10][17].
Anderson, N. - Dovetail Blog: "Use a Job Atlas to Share Your JTBD Research"[65][60].
Shavin Peiries - Four Forces model overview[28][81].
Dscout People Nerds: N. Anderson, "Studying Users Who Switch Products? Try Jobs to Be Done"[39][48].
New Markets Advisors - "Jobs to be Done Framework" and "Journey Mapping Meets JTBD"[22][69].
Spatial, R.D. - "Jobs Theory and the Four Forces of Progress" (Blog)[29][32].

Applying Jobs-to-Be-Done (JTBD) in Product & UX Research

What is the Jobs-to-Be-Done (JTBD) Framework?

Key Elements of a Well-Formed JTBD

Good vs. Weak JTBD Statements

JTBD vs. Latent Needs Assessment: Overlaps & Differences

JTBD Research Frameworks