Introduction

Two products can offer similar features, target the same audience, and compete in the same category, yet customers consistently prefer one over the other. The difference often comes down to how well the product helps users achieve a meaningful outcome in their daily work. The jobs-to-be-done (JTBD) framework gives product managers and founders a practical way to understand customer intent, uncover unmet needs, and make stronger decisions about product, positioning, and prioritization. In this guide, we will break down how the jobs-to-be-done framework works, how teams apply it in product management, and how to write effective JTBD statements with practical examples.

What is the jobs-to-be-done (JTBD) framework?

The jobs-to-be-done (JTBD) framework is a customer research and product strategy approach that helps teams understand why people choose specific products, services, or workflows. Instead of focusing only on user demographics, feature requests, or product categories, the framework focuses on the progress customers want to make in a particular situation.

At the center of the jobs-to-be-done theory is a simple idea: customers “hire” products to help them solve a problem or achieve a desired outcome. When the product helps them make meaningful progress, they continue using it. When it creates friction or fails to support the outcome effectively, customers look for alternatives.

For product teams, the JTBD framework creates a clearer understanding of customer needs, buying behavior, prioritization decisions, and product adoption patterns.

What does “job” mean in JTBD?

In the jobs-to-be-done framework, a “job” represents the goal or progress a customer wants to achieve in a specific context. It goes beyond a surface-level task and focuses on the reason behind the behavior.

For example, a product manager creating a sprint board is completing a task. The actual job may involve improving team coordination, reducing delivery confusion, and helping stakeholders better understand project progress.

This distinction matters because customers rarely evaluate products based only on features. They evaluate whether the product helps them move toward a desired outcome efficiently.

The core idea behind JTBD

The core principle behind the JTBD framework is that customers choose products based on the outcome they want, not the product category itself.

A customer searching for a project management platform may simultaneously compare spreadsheets, chat tools, issue trackers, documentation systems, and project management software, because each can help address different aspects of the same underlying problem.

This changes how teams think about competition, product discovery, and customer research. Instead of asking, “Which features should we build next?” teams start asking, “What progress is the customer trying to make, and where does friction exist today?”

That shift often leads to stronger product decisions because it connects development priorities directly to customer outcomes.

Where did the JTBD framework come from?

The jobs-to-be-done (JTBD) framework grew from research focused on one important question: why do customers choose one product over another? Two names are closely connected to the framework: Tony Ulwick and Clayton Christensen. Their work helped shape how modern product teams think about customer needs, innovation, and product strategy.

Tony Ulwick and Outcome-Driven Innovation (ODI)

Tony Ulwick introduced many of the early concepts behind outcome-driven product thinking through his Outcome-Driven Innovation (ODI) framework. His work focused on understanding the outcomes customers want when a job is completed. Instead of asking customers which features they wanted, Ulwick encouraged teams to study what customers were actually trying to achieve and where friction existed in the process.

For example, a team using a reporting dashboard may want faster visibility into project delays, clearer progress tracking, or easier decision-making during sprint reviews. Those desired outcomes provide stronger product direction than a simple request for more charts or filters.

This approach helped organizations identify unmet customer needs and prioritize improvements based on customer importance and struggle.

Clayton Christensen and the “hire” theory

Clayton Christensen later helped popularize the jobs-to-be-done framework through his work on innovation and product strategy. He introduced the idea that customers “hire” products or services to help them complete a specific job.

This made the framework easier for product teams to understand and apply.

One of Christensen’s most widely discussed examples involved milkshakes purchased during morning commutes. Researchers found that customers often bought milkshakes because they wanted something filling, convenient, and easy to consume while driving. In that situation, the milkshake competed with snacks, coffee drinks, and breakfast items serving the same underlying job.

The example showed that products compete based on the outcome customers want, not only on the product category.

Why the framework became popular in product management

The JTBD framework became popular in product management because it gave teams a clearer way to understand customer behavior and product adoption.

As software products became more competitive, teams needed better ways to understand:

• Why customers adopted products,
• What problems created friction?
• Why users switched tools,
• And which outcomes mattered most.

The jobs-to-be-done framework helped teams connect customer research directly to product discovery, prioritization, onboarding, positioning, and roadmap planning.

Today, many product managers, founders, and UX researchers use JTBD to build products around customer outcomes instead of isolated feature requests.

Why the jobs-to-be-done framework matters

The Jobs-to-be-Done (JTBD) framework helps teams move beyond raw data to understand the true motivations behind customer behavior. By identifying the specific progress users want to achieve, JTBD streamlines decision-making across product, marketing, and UX.

Here is why the JTBD framework matters:

1. It shifts teams from feature thinking to outcome thinking

Many teams naturally focus on shipping features, expanding functionality, or matching competitor capabilities. The JTBD framework shifts attention toward the outcome customers are trying to achieve. For example, a customer may request better reporting filters, but the deeper goal could be to identify delivery risks more quickly during sprint reviews. Understanding that outcome helps teams prioritize solutions more effectively. This approach often leads to products that solve meaningful workflow problems instead of adding surface-level functionality.

2. It helps uncover real customer motivations

Customers usually describe solutions during interviews, while their real motivation sits underneath the request itself. A team asking for more notifications may actually want faster stakeholder alignment. A manager requesting additional dashboards may want clearer visibility into delivery bottlenecks across projects. The jobs-to-be-done framework helps teams identify the underlying motivation behind customer behavior, making research insights more actionable for product and UX decisions.

3. It reveals unmet customer needs

JTBD helps organizations identify gaps between what customers want to accomplish and how effectively their current solutions support those goals. These gaps often reveal opportunities for product improvement, workflow simplification, automation, onboarding enhancements, or entirely new product experiences. Instead of prioritizing requests solely by volume, teams can evaluate which customer outcomes remain underserved or difficult to achieve.

4. It helps teams understand competitors more accurately

One of the most valuable aspects of the jobs-to-be-done framework is how it changes the way teams think about competition. Customers rarely compare products only within the same software category. They compare anything that helps solve the same underlying job.

5. It improves product discovery and prioritization

The JTBD framework provides product teams with a stronger context for product discovery and roadmap planning. Instead of prioritizing features based only on requests or assumptions, teams can evaluate:

• Which workflows create the most friction?
• Which outcomes do customers value most?
• And which problems affect adoption, retention, or efficiency?

This leads to more focused prioritization and clearer product direction.

6. It creates stronger positioning and messaging

Products become easier to position when teams understand the real progress customers want to make. Messaging built around customer outcomes usually resonates more clearly than messaging focused only on features or technical capabilities.

Core principles of the jobs-to-be-done framework

These core principles form the foundation of the framework and explain why many product teams use JTBD during product discovery, customer research, roadmap planning, and positioning.

1. Customers want progress, not products

Customers rarely search for products simply because they want new software or additional features. They look for ways to solve problems, reduce friction, save time, improve coordination, or achieve better outcomes.

A team adopting a project management platform may want clearer ownership, faster execution, and better visibility across projects. The product becomes valuable because it helps the team make progress toward those goals. This principle helps product teams focus on customer outcomes instead of feature output alone.

2. Jobs stay stable while solutions evolve

Technology, workflows, and product categories continue to change, but many customer jobs remain consistent over time. Teams have always needed ways to coordinate work, share knowledge, track progress, and manage deadlines. The tools supporting those jobs evolved from spreadsheets and email threads to modern project management and collaboration platforms. Understanding stable customer jobs helps organizations build products around long-term needs instead of short-term trends.

3. Jobs are solution-agnostic

Customers usually care more about achieving the outcome than about the specific tool they use to get there. For example, a startup founder trying to improve project visibility may compare project management software, spreadsheets, documentation tools, dashboards, or even custom workflows. Each option solves part of the same underlying job. This principle changes how teams think about competition. Products compete with any alternative helping customers accomplish the same goal.

4. Jobs include functional, emotional, and social dimensions

Customer decisions often involve more than practical workflow needs. The JTBD framework recognizes that jobs have functional, emotional, and social dimensions simultaneously.

A product manager may want:

• Functional progress through better sprint planning,
• Emotional confidence during stakeholder reviews,
• And social credibility while presenting delivery updates to leadership teams.

Understanding these layers helps teams design products and messaging that connect more closely with customer expectations and real-world behavior.

5. Desired outcomes define customer success

In the jobs-to-be-done framework, customer success is measured by how effectively the desired outcome is achieved.

For example, a customer using a reporting dashboard may care about:

• Identifying risks earlier,
• Reducing manual status updates,
• Improving decision-making speed,
• Or increasing visibility across teams.

These outcomes provide stronger product direction than isolated feature requests because they connect directly to customer value. Product teams often use desired outcomes to guide prioritization, onboarding improvements, workflow optimization, and product strategy decisions.

6. Customer context matters as much as customer behavior

Customer decisions make more sense when teams understand the context surrounding them. The same customer may choose different tools depending on:

• Team size,
• Workflow complexity,
• Time pressure,
• Stakeholder involvement,
• Or operational constraints.

The JTBD framework encourages teams to study customer context alongside customer actions. That combination creates a more complete understanding of adoption behavior, friction points, and product expectations.

Types of jobs in the JTBD framework

The Jobs-to-be-Done (JTBD) framework categorizes customer needs to decode complex decision-making. By analyzing practical, emotional, social, and workflow drivers, product teams can optimize user experiences, refine positioning, and uncover hidden insights. Let’s explore the primary types of jobs within the JTBD framework:

1. Functional jobs

Functional jobs represent the practical task or outcome a customer wants to accomplish. This is usually the most visible part of the job and often becomes the starting point for product discovery.

For example, a project manager may use a project management platform to:

• Organize sprint work,
• Assign ownership,
• Track deadlines,
• And monitor delivery progress.

These are functional goals tied directly to execution and workflow efficiency. Most feature requests and product comparisons happen at the functional level because customers naturally describe the practical problem they are trying to solve.

2. Emotional jobs

Emotional jobs focus on how customers want to feel during or after completing the job.

A product manager managing multiple projects may want to feel:

• Confident during stakeholder reviews,
• Less overwhelmed by delivery chaos,
• And more in control of project timelines.

These emotional expectations often influence adoption and retention more strongly than teams initially realize.

Products that reduce stress, improve clarity, or create confidence can become significantly more valuable in day-to-day workflows, even when competing products offer similar functional capabilities.

3. Social jobs

Social jobs relate to how customers want to be perceived by other people.

For example, an engineering manager may want to appear:

• Organized,
• Proactive,
• Data-driven,
• And reliable while presenting delivery updates to leadership teams.

Similarly, founders may want tools that help them communicate operational clarity to investors or cross-functional teams.

Social jobs play an important role in B2B software adoption because workplace tools often influence collaboration, reporting, communication, and visibility into decision-making across organizations.

4. Related jobs

Related jobs are supporting activities connected to the primary customer job. These jobs may happen before, during, or after the main workflow. For example, a team adopting a project management platform to coordinate delivery work may also need to:

• Document decisions,
• Share sprint updates,
• Manage stakeholder communication,
• Track dependencies,
• And maintain project visibility across teams.

These supporting workflows shape the overall customer experience and often influence product adoption, workflow efficiency, and long-term retention. Teams that understand related jobs can build more connected product experiences instead of solving isolated workflow problems.

The anatomy of a job-to-be-done

A customer's job involves more than a single action or purchase decision. Every job contains a broader context that shapes why customers look for solutions, what outcomes they care about, and how they evaluate available options.

Breaking the job into smaller components helps product teams better understand customer behavior during product discovery, research, positioning, and roadmap planning.

1. Situation or context

Every job starts with a situation that creates the need for progress or change. Context plays a major role in shaping customer decisions because the same customer may behave differently depending on their environment, workload, team structure, or operational pressure.

For example, a startup team managing five projects through spreadsheets may begin searching for project management software after remote collaboration increases and delivery visibility becomes harder to maintain.

The situation explains when the need appears and what conditions make the job important.

2. Motivation

Motivation explains why the customer starts looking for a solution. This usually happens when existing workflows create friction, inefficiency, delays, confusion, or operational stress. Customers begin evaluating alternatives when the current way of working no longer effectively supports the outcome they want.

For example, an engineering manager may look for a better workflow system because status updates take too much time, project ownership is unclear, and sprint coordination slows across teams.

Understanding motivation helps teams identify the underlying reasons behind customer behavior rather than focusing solely on feature requests.

3. Desired outcome

The desired outcome defines what success looks like for the customer after the job is completed. In the jobs-to-be-done framework, outcomes matter because customers evaluate products based on how effectively they help achieve those results.

For example, a product team adopting a project management platform may want:

• Clearer project visibility,
• Faster coordination,
• Reduced delivery bottlenecks,
• And better alignment across engineering, product, and design teams.

Desired outcomes often shape adoption, satisfaction, retention, and long-term product value more strongly than individual features.

4. Constraints and frustrations

Constraints represent the obstacles preventing customers from completing the job efficiently today.

These issues may involve:

• Scattered communication,
• Manual workflows,
• Disconnected tools,
• Unclear ownership,
• Reporting delays,
• Or operational complexity.

For example, teams managing work across spreadsheets, chat tools, and documentation systems may struggle with fragmented visibility and inconsistent project updates.

Understanding frustrations helps product teams identify where workflow friction creates opportunities for improvement.

5. Existing alternatives

Customers rarely start from zero when trying to solve a problem. Most already use some combination of tools, manual workflows, spreadsheets, internal processes, or competing platforms to complete the job. These alternatives form the customer’s baseline for comparison.

For example, a team evaluating project management software may currently rely on:

• Spreadsheets for tracking work,
• Chat tools for coordination,
• Documents for project planning,
• And meetings for status reporting.

The jobs-to-be-done framework helps teams understand why customers continue to use existing workflows, what limitations cause dissatisfaction, and what factors influence switching decisions.

Jobs-to-be-done examples

The jobs-to-be-done (JTBD) framework becomes easier to understand when viewed through the lens of real-world workflows and customer decisions. These examples show how customers “hire” products to help them make progress toward a specific outcome rather than simply use a set of features.

1. Productivity software example

A growing product and engineering team may adopt a project management platform after coordination across spreadsheets, chat threads, and status meetings becomes difficult.

At the surface level, the team appears to be looking for features like task tracking, sprint planning, and project timelines. The deeper job involves:

• organizing work clearly,
• improving ownership visibility,
• reducing delivery confusion,
• and helping teams move projects forward efficiently.

In this situation, the platform helps the team create structure, maintain alignment, and improve execution across workflows.

This is why many teams evaluate project management tools based on workflow clarity and operational visibility rather than feature count alone.

2. Documentation and knowledge management example

A distributed organization may introduce a documentation platform after teams begin struggling with scattered information and repeated questions across departments.

The functional job involves storing and retrieving information efficiently, but the broader job includes:

• Reducing knowledge silos,
• Improving onboarding,
• Making decisions easier to trace,
• And helping teams quickly find reliable information.

For example, engineering teams may need centralized technical documentation, product teams may require roadmap visibility, and support teams may look for updated process documentation in a single workspace.

In this case, the documentation platform becomes valuable because it improves organizational clarity and reduces the time spent searching for context across disconnected systems.

How to write a jobs-to-be-done statement

A jobs-to-be-done (JTBD) statement helps teams capture the real customer goal behind a product decision or workflow behavior. It creates a structured way to describe what customers are trying to achieve, why the need appears, and what outcome defines success.

Most JTBD statements follow a simple format: When [situation], I want to [motivation/action], so I can [desired outcome].

This structure helps product teams move beyond feature requests and focus on customer progress in a specific context.

For example: When managing multiple product releases across teams, I want to track dependencies and delivery progress in one place to reduce delays and improve coordination.

A strong JTBD statement usually focuses on:

• The situation creates the need,
• The customer’s underlying motivation,
• And the outcome they want to achieve.

JTBD statement structure explained

Each part of the statement provides important customer context.

This structure works well because it keeps teams focused on customer outcomes instead of product features.

Good vs. bad JTBD statements

Weak JTBD statements usually focus too heavily on the product itself, whereas strong statements clearly explain the customer’s situation, motivation, and expected outcome.

Strong JTBD statements give product, design, and engineering teams better context for prioritization, workflow design, messaging, and customer research.

Common mistakes when writing JTBD statements

Many JTBD statements fail because they describe products or activities instead of the customer’s actual goal. A strong jobs-to-be-done statement should explain the situation, the motivation behind the action, and the outcome the customer wants. Here are some common mistakes teams make.

1. Focusing on the product

Many teams write statements about the solution rather than the customer's problem. For example, “I need a project management tool for sprint planning” focuses on the product category. A stronger JTBD statement explains the real goal, such as improving coordination across teams or reducing delivery confusion. The framework works best when teams focus on customer progress instead of tools.

2. Making the statement too broad

Broad statements create vague insights and weak prioritization decisions. For example, “I want better collaboration” can mean completely different things across teams. A stronger statement clearly explains the context and the expected outcome. Specific statements make customer needs easier to understand and act on.

3. Writing tasks instead of outcomes

Another common mistake is describing activities instead of the results customers care about. For example, “I want to create project reports” describes a task. The actual outcome may involve improving stakeholder visibility or identifying project risks faster. Good JTBD statements focus on the progress customers want to make, not just the action they perform.

JTBD vs. personas vs. user stories

JTBD, personas, user stories, and customer journey maps all help teams understand customers, but they answer different questions. JTBD explains why customers look for a solution. Personas explain who the customer is. User stories explain what users need inside the product. Journey maps explain how users move through an experience.

When teams should use JTBD

Teams should use the jobs-to-be-done framework to understand why customers choose, switch, or continue using a product. It is especially useful during product discovery, market research, roadmap planning, and positioning work.

JTBD works well when teams are trying to answer questions like "What progress is the customer trying to make?" What outcome matters most? What alternatives are they using today? What friction pushes them to search for something better?

When personas or user stories work better

Personas work better when teams need to understand audience segments, roles, buying committees, or user groups. For example, a founder, product manager, and engineering manager may care about the same product but evaluate it through different priorities.

User stories work better when teams are ready to translate customer needs into product requirements. They help engineering, product, and design teams define specific interactions, workflows, and acceptance criteria.

Why do many teams combine these frameworks

Most teams get the best results when they combine these methods. JTBD explains the deeper customer motivation. Personas add role and audience context. User stories turn insights into buildable product work. Journey maps show where friction appears across the experience.

Together, they help teams connect customer research with product strategy, roadmap planning, and delivery execution.

Benefits of using the jobs-to-be-done framework

The jobs-to-be-done (JTBD) framework helps teams better understand customer decisions. Instead of focusing only on features, user segments, or product usage patterns, teams begin focusing on the progress customers want to make and the outcomes driving their behavior. This creates stronger decisions on product, strategy, and customer experience across the organization. Let’s explore the key benefits of the JTBD framework:

1. Better customer understanding

JTBD helps teams understand why customers seek solutions, which problems create friction, and which outcomes matter most in their workflows. This gives product teams deeper customer insight than feature requests or usage metrics alone because it explains the motivation behind the behavior.

2. Stronger product strategy

Product strategy becomes more focused when teams understand the core job their product is helping customers complete. The framework helps organizations identify which problems matter most, where workflows break down, and which improvements create the highest customer value.

3. More effective prioritization

Many product teams struggle with prioritization because customer requests compete constantly. JTBD helps teams prioritize work based on customer outcomes and workflow impact instead of request volume alone. This often leads to clearer roadmap decisions and more meaningful product improvements.

4. Clearer messaging and positioning

Products become easier to position when teams understand the progress customers want to make. Messaging built around outcomes usually connects more clearly with customer needs than messaging focused only on features or technical capabilities.

5. Improved innovation opportunities

The JTBD framework helps teams identify unmet needs and workflow gaps more effectively. When organizations understand where customers experience friction, they can discover opportunities for improved workflows, automation, onboarding, and new product experiences.

6. Better cross-functional alignment

JTBD creates a shared understanding of customer goals across product, engineering, design, marketing, and support teams. This helps teams make decisions around the same customer outcome instead of interpreting feedback separately across departments.

Final thoughts

The jobs-to-be-done (JTBD) framework helps teams move beyond feature requests and surface-level customer feedback to understand what users are actually trying to accomplish. By focusing on customer progress, desired outcomes, and workflow friction, teams can make stronger decisions across product discovery, prioritization, positioning, and user experience.

For product managers, founders, and engineering leaders, JTBD provides a more reliable way to build products around real customer needs rather than assumptions. Teams that understand the job behind customer behavior often build clearer workflows, stronger product experiences, and more valuable solutions over time.

Frequently asked questions

Q1. What are some JTBD examples?

Some common jobs-to-be-done examples include:

• Teams using project management software to improve coordination and delivery visibility,
• Companies adopting documentation platforms to centralize knowledge,
• Managers using dashboards to track project risks faster,
• And customers choosing food delivery apps to save time during busy schedules.

In each case, the customer is trying to make progress toward a specific outcome instead of simply using a product feature.

Q2. What are the three main types of jobs-to-be-done?

The three main types of jobs-to-be-done are:

• Functional jobs,
• Emotional jobs,
• And social jobs.

Functional jobs focus on practical goals, emotional jobs focus on how customers want to feel, and social jobs focus on how customers want to be perceived by others.

Q3. What is an example of a job to be done drill?

A classic JTBD drill example is that customers do not actually want a drill. They want a hole in the wall to complete another goal, such as hanging a shelf or organizing a workspace. The example highlights an important JTBD principle: customers value the outcome the product creates more than the product itself.

Q4. What are the 4 types of job design?

The four common types of job design in organizational management are:

• job rotation,
• job enlargement,
• job enrichment,
• and job simplification.

These concepts relate to workplace role structuring and employee responsibilities, which differ from the jobs-to-be-done framework used in product management and customer research.

Q5. What are JTBD jobs-to-be-done?

JTBD stands for jobs-to-be-done. It is a product and customer research framework that helps teams understand why customers choose products, what progress they want to make, and which outcomes shape their decisions. The framework is widely used in product management, UX research, innovation strategy, and product positioning.