What Are Jobs to Be Done (JTBD)? Framework, Examples and How to Use It

Jobs to be done (JTBD) is a product thinking approach. It says customers "hire" a product to make progress in a specific situation. The unit of analysis is the job the customer wants done, not the customer's age, role or profile.

To use it, interview customers about a recent purchase or switch. Write job statements in the "When, I want to, so I can" format. Map the job steps and rate the outcomes by importance and satisfaction. Then turn the underserved outcomes into backlog items.

Key Highlights of Jobs to Be Done(JTBD):

• JTBD is a product approach that treats every purchase as a "hire." Customers choose a product to make progress on a specific job in a specific situation.
• The idea comes from Tony Ulwick's Outcome-Driven Innovation and Clayton Christensen's work. The milkshake story shows that real competition can be bananas, bagels and boredom, not other milkshakes.
• Customers hire products for three kinds of jobs. These are functional (the task), emotional (how they want to feel) and social (how they want to be seen).
• A strong job statement follows the "When, I want to, so I can" format. It stays free of solutions, and it ties to one situation.
• The step-by-step method has four stages: interview customers, map job steps and outcomes, find underserved needs through importance and satisfaction scores, then prioritize and feed the backlog.
• JTBD works alongside user personas, user stories, product discovery and the value proposition canvas. It helps Product Owners and Product Managers link backlog items to customer outcomes in agile and SAFe teams.

Introduction

Most product teams do not fail because they cannot build. They fail because they build the wrong thing. They ask customers what features they want, and customers describe solutions they have already seen. The roadmap fills up with requests that do not move the needle.

JTBD offers a different starting point. It asks why a customer reached for your product at all. What were they trying to get done? What was going on in their life at that moment? What else did they consider?

These questions change how teams discover problems and set priorities. They also fit well with agile product work. If you are a Product Owner or Product Manager, JTBD gives you a sharper way to explain value and defend the order of your backlog.

This guide covers the definition, the history and the main job types. It then explains job statements, a step-by-step method, real examples and common mistakes. It also shows how JTBD works in SAFe teams.

What Are Jobs to Be Done?

Jobs to be done is a lens for understanding why people buy, switch or quit. It treats every purchase as a hire. A customer has a job. They look for something to do it. They pick a product, use it, and fire it when something better comes along.

This lens sounds simple, but it shifts attention. You stop asking "Who is our customer?" and start asking "What progress is our customer trying to make?"

Jobs to Be Done Definition

A job is the progress a person wants to make in a particular circumstance. Three parts matter in that definition.

• Progress: The customer wants a change from where they are now to where they want to be.
• Circumstance: The situation shapes the need. The same person wants different things on a Monday commute and a Sunday evening.
• Struggle: There is a gap between the current state and the desired state. That gap creates demand.

A job is not a product feature. It is also not a task like "click the save button." It is stable and solution-free. People wanted to listen to music on the move long before portable players existed. The job stayed the same while the products changed from cassettes to CDs to streaming.

This is why JTBD lasts. Technologies and competitors change. Jobs stay put, so a team that understands the job can adapt to new technology faster.

The Origin (Clayton Christensen and Tony Ulwick)

The idea has two main roots. Tony Ulwick developed the early practice in the 1990s while working on product innovation at IBM. He later founded the consulting firm Strategyn. He built a method called Outcome-Driven Innovation (ODI), which treats the job as the unit of analysis and measures customer outcomes.

Clayton Christensen, the Harvard Business School professor known for disruptive innovation, brought the idea to a wide audience. He argued that customers "hire" products to do jobs. He explored the idea in works such as The Innovator's Solution and later in his book Competing Against Luck.

The two schools overlap but differ in emphasis. Ulwick's approach is quantitative. It focuses on job steps, desired outcomes and opportunity scoring. The Christensen-linked school, shaped by practitioners like Bob Moesta, is more narrative. It focuses on the story of a purchase, including the forces that push and pull a person toward a switch.

Both belong to the wider jobs to be done theory. You do not have to pick one side. Many teams use interviews to find the story and structured outcomes to size the opportunity.

The Milkshake Example That Made It Famous

The best-known JTBD story Know Your Customers’ “Jobs to Be Done” – Harvard Business Review (Christensen et al., 2016) involves a fast-food chain that wanted to sell more milkshakes. The usual research did not help. The team profiled typical milkshake buyers and asked what they wanted. Customers asked for thicker, cheaper or more chocolatey shakes. The changes did not lift sales.

Then researchers watched who bought milkshakes and when. A large share of sales happened early in the morning. The buyers were mostly commuters, alone in their cars, with a long and boring drive ahead.

When asked what job the milkshake did, the answers were revealing. The commuters wanted something to make the drive more interesting. They also wanted something that would keep them full until lunch, that was easy to hold with one hand, and that would not make a mess. The banana was gone too fast. The bagel was messy. A doughnut left them hungry by mid-morning. The thick milkshake took a long time to drink through a thin straw, and that suited the commute.

The competitors were not other milkshakes. They were bananas, bagels, doughnuts and boredom. This is the lesson. When you define the job, you see the real competition and the real improvement ideas. In this case, a thicker shake with fruit chunks made sense for the morning crowd.

The Types of Jobs Customers Hire Products For

Jobs are not only practical. Customers also want to feel a certain way and be seen a certain way. Strong JTBD work looks at all three dimensions.

1. Functional Jobs

Functional jobs are the practical tasks a customer wants to complete. They are the most visible kind and the easiest to research.

Examples include moving money to a friend, tracking project risks, or cooking a healthy dinner in twenty minutes. A good functional job is clear and measurable. You can tell whether the customer got it done and how well.

Most teams begin here because functional jobs link directly to features and metrics. But they only tell part of the story.

2. Emotional Jobs

Emotional jobs describe how the customer wants to feel, or avoid feeling, while getting the job done. They cover confidence, relief, control, safety and pride.

Think about someone using a budgeting app. The functional job is tracking spending. The emotional job may be to stop feeling anxious about money at the end of the month. Two apps can offer the same features. The one that delivers calm will win loyalty.

Emotional jobs often explain why customers switch for reasons that look irrational on paper. They can also guide tone, onboarding and support design.

3. Social Jobs

Social jobs concern how the customer wants to be perceived by others. People choose products partly to signal something about themselves. They may want to look competent to a manager, responsible to their family, or modern to their peers.

A professional who earns a certification often has a social job too. They want to be seen as credible in the team and in the market. A product team that ignores social jobs may overlook a strong reason for adoption.

When you map all three types, you get a fuller picture. A customer rarely hires a product for one reason alone.

The JTBD Framework and Job Statements

The JTBD framework gives structure to the idea. It helps you write jobs in a consistent way, break them into steps, and measure which parts of the job are poorly served. Without that structure, "customer jobs" can become vague slogans.

The Job Statement Format (When, I Want To, So I Can)

A job statement captures the job in one clear sentence. The most popular format has three parts.

When [situation], I want to [motivation], so I can [expected outcome].

This format is often called a job story. It became popular through Intercom as an alternative to the classicuser story. Here are a few examples.

• When I finish a customer call, I want to log the key points quickly, so I can follow up without forgetting anything.
• When I plan a sprint, I want to see which items carry the most customer value, so I can commit to the right work.
• When I am hungry at 4 pm, I want a snack that is filling and light, so I can stay focused until dinner.

Notice what is missing. There is no persona, no age and no interface. The situation sets the context, the motivation states the need, and the outcome shows the real benefit.

A strong JTBD job statement follows a few rules.

• Keep it free of solutions. Do not mention an app, a button or a feature.
• Make it specific to a situation, not a general wish.
• Use plain language the customer would use.
• Focus on one job at a time.

If you want to practice, a simple jobs to be done template helps. Create a table with columns for situation, motivation, outcome, current solution, and struggle. Fill one row per job you hear in interviews. Teams can reuse this sheet across projects and share it in workshops.

Main Jobs, Related Jobs and Job Steps

A good JTBD analysis separates three layers.

The main job is the core job the customer wants done. For a project manager, it might be "keep a project on track."

Related jobs are the other jobs that appear around it. These include reporting to stakeholders, managing team morale or planning resources. Related jobs reveal adjacent opportunities.

Job steps break the main job into stages. Ulwick's model describes a universal sequence. Customers define what they want, locate the inputs, prepare, confirm they are ready, execute, monitor, modify and conclude. Not every job needs all eight steps, but the sequence helps you avoid missing a stage.

Take the main job "get a home loan." The steps might include working out what I can afford, finding lenders, gathering documents, checking readiness, submitting the application, tracking progress, fixing errors and closing. Each step can contain friction. Each friction point is a possible opportunity.

Outcome-Driven Innovation

Outcome-Driven Innovation (ODI) turns job steps into measurable customer outcomes. An outcome is a metric customers use to judge how well the job is done. Ulwick writes outcome statements in a fixed pattern: a direction, a metric, an object and a context.

For example: "Minimize the time it takes to find the right document when preparing a loan application."

Customers then rate each outcome on two scales: how important it is, and how satisfied they are with current solutions. Outcomes that are highly important but poorly satisfied are the underserved ones. 

A high score signals a real chance to create value. A low score on an important outcome means the market already serves it well. A high satisfaction score on an unimportant outcome may signal over-engineering.

This is where JTBD becomes a practical methodology rather than a mindset. It gives a repeatable way to compare needs and choose where to invest.next to the opportunity score formula.Outcome-Driven Innovation – Wikipedia explains ODI and the opportunity scoring formula. You could also link Ulwick’s own page onStrategyn.

How to Apply Jobs to Be Done Step by Step?

The jobs to be done methodology can be run in a few weeks with a small team. The steps below combine interview-led discovery with outcome measurement.

Step 1: Interview Customers About the Job

Start with a JTBD interview. The goal is to understand a real decision, not to collect opinions. Interview people who recently bought, switched or cancelled. Memory is fresh, and the story is more reliable.

Begin at the moment before the purchase. Ask what was happening in their life. Ask when they first thought about changing something. Then follow the timeline forward through searching, comparing, deciding and using.

Useful questions include these.

• What was going on when you first looked for a solution?
• What were you using before?
• What else did you consider?
• What almost stopped you from buying?
• What was the first moment you knew it was working?

Listen for four forces that shape a switch. The push of the current situation. The pull of the new solution. The anxiety about changing. The habit of staying with the old way. Those forces explain why people move and why they stay.

Avoid leading questions. Do not ask "Would you like feature X?" Ask about past behavior instead. Aim for five to ten interviews per customer segment, then look for patterns.

Step 2: Map the Job Steps and Outcomes

Next, build a job map. Unlike acustomer journey map, which follows a customer’s experience with your product, a job map follows the job itself, independent of any solution.

For each step, capture the desired outcomes in plain, measurable language. Write them in the "minimize" or "increase" pattern. Keep each outcome free of solutions.

A simple job map can sit in a spreadsheet or on a whiteboard. Columns show the steps. Rows show the outcomes, the pain points and the workarounds customers use. Workarounds are especially valuable. When a customer builds a spreadsheet or sticky-note system to fill a gap, they are telling you something is missing.

Step 3: Find Underserved Needs

Now quantify. Create a short survey that lists your outcome statements. Ask a sample of target customers to rate each outcome for importance and satisfaction, using a five-point or ten-point scale.

Calculate the opportunity score for each one. Plot importance against satisfaction. Outcomes in the high importance, low satisfaction corner are your underserved needs.

This step also supports a fair JTBD analysis. It reduces the pull of loud opinions and gives the team shared data. It can also show which segments value which outcomes, so you can group customers by shared needs instead of by demographics.

Step 4: Prioritize and Feed the Backlog

Finally, turn insight into work. Link each underserved outcome to possible solutions. Write them as epics, features or experiments. Attach the job statement and the target outcome to each backlog item so the reason stays visible.

Thenprioritize the product backlogusing the opportunity scores alongside effort, risk and strategy. Run small tests before large builds. Measure whether the outcome improves for real users, not just whether the feature shipped.

This closes the loop. The backlog now reflects customer progress, not internal assumptions.

Jobs to Be Done Examples

Examples make the theory real. The cases below show how the same lens works across different markets.

• Streaming and entertainment. Netflix has described competing with sleep, social media and other ways people spend free time. The job is to unwind after a long day. The rival is not only other streaming services. It is anything that fills the evening.
• Ride-hailing. A rider has the job of "getting to the airport on time without worrying." The functional need is transport. The emotional need is certainty. Live tracking and fixed price estimates address the anxiety, not just the journey.
• B2B software. A project manager hires a tool to keep stakeholders informed. The job is "when a sponsor asks for status, I want an accurate view in seconds, so I can avoid a long meeting." Features like dashboards matter only if they serve that job.
• Professional learning. A mid-career professional enrolls in a certification course. The functional job is gaining product ownership skills. The emotional job is feeling confident in a new role. The social job is being seen as ready for a larger responsibility.

These jobs to be done framework examples share a pattern. The best insight comes from the situation and the struggle. When you see those, the right product and message become clearer.

Jobs to Be Done vs Personas and User Stories

JTBD does not replace every other tool. It complements them. Understanding the differences helps you use each one well.

Auser personadescribes a representative customer. It includes goals, behaviors, frustrations and context. Personas help teams build empathy and keep a human face in mind. Their weakness is that they can drift into demographics and stereotypes. Two people with the same profile can hire products for very different reasons.

JTBD focuses on the situation and motivation. It explains why people act, not just who they are. Many teams combine the two. They use jobs to define needs and personas to describe the people who face them.

The comparison of jobs to be done vs user stories is often misunderstood. A job sits above the story. One job can lead to many user stories. The job explains the "why" in context. The story describes the "what" for the team.

Use jobs to frame the problem, personas to humanize it, and stories to deliver the solution.

Using JTBD in Agile and SAFe Product Work

JTBD fits naturally into agile teams. It improves the front end of the process, where ideas are shaped before they become work items. In scaled settings, it also helps align many teams around a shared view of customer value.

From Jobs to Features and Backlog Items

Here is a practical flow for a Product Owner or Product Manager.

1. Capture the main job and related jobs from research.
2. Convert underserved outcomes into hypotheses.
3. Writeepicsthat state the job and the target outcome.
4. Split epics into features and user stories.
5. Defineacceptance criteria that reflect the outcome, not just the function.
6. Measure results after release and adjust.

JTBD also strengthensproduct discovery. Discovery is the work of learning what to build before committing to build it. Jobs give discovery a clear target. Instead of exploring every idea, the team explores ways to help customers make progress on a defined job.

The value proposition canvas is another close partner. Its customer profile has three parts: jobs, pains and gains. Its value map has products and services, pain relievers and gain creators. JTBD research fills the customer side with real evidence. The canvas then helps you check whether your offer fits.

For teams working in the Scaled Agile Framework, these ideas support the work of the Product Owner and Product Manager. If you want to see how the role fits into the framework, read aboutSAFe POPM roles and responsibilities.

JTBD and Customer Centricity

SAFe treatscustomer centricityas a core mindset within its Agile Product Delivery competency. It asks teams to understand customers deeply and to design solutions with them in mind. JTBD gives a concrete method for doing so.

A few ways it helps in practice:

• It creates a shared language across teams. Everyone can talk about the same job and the same outcomes.
• It reduces feature debates. The conversation moves from "I think we need this" to "Which outcome does this improve?"
• It supports better roadmaps. Themes can be organized around jobs instead of departments.
• It connects strategy to delivery. Product Managers can link a portfolio theme to a job, and Product Owners can link stories to the same job.

For professionals who want to build these skills formally, theSAFe POPM Certification Training covers how to work with customer needs, write backlog items and prioritize value across teams.

Common JTBD Mistakes

Even strong teams stumble when they first apply JTBD. Watch for these traps.

• Defining the job as a solution. "Use a mobile banking app" is not a job. "Pay a friend back quickly without awkwardness" is. If your statement names a product, rewrite it.
• Making the job too broad or too narrow. "Live a good life" is too broad to act on. "Tap the pay button" is too narrow. Aim for a level where you can see steps and outcomes.
• Confusing tasks with jobs. A task is an activity. A job is the progress behind it. Ask why until you reach the real goal.
• Skipping emotional and social jobs. Many teams stop at functional needs. They then wonder why a feature-rich product loses to a simpler one.
• Interviewing the wrong people. Long-time loyal users may not remember why they chose you. Talk to recent switchers, new buyers and lapsed users too.
• Asking for opinions, not stories. Questions like "What would you like?" produce wish lists. Questions about the last time they struggled produce insight.
• Treating JTBD as a one-time workshop. Jobs are stable, but contexts and competitors shift. Revisit the research regularly.
• Ignoring the numbers. Interviews give depth. Surveys and usage data give scale. Use both.

Conclusion

JTBD turns product thinking from "What can we build?" into "What progress does the customer need?" It sharpens discovery, clarifies competition and gives teams a language for value. Used with personas, user stories and the value proposition canvas, it helps you build products that people actually hire and keep.

Start small. Pick one customer segment. Run five interviews. Write ten job statements. Score the outcomes and move the top three into your backlog. You will quickly see how much clearer prioritization becomes.

If you want to apply these ideas with confidence in a real agile environment, structured learning helps. Simpliaxis offers theSAFe POPM Certification Training for Product Owners and Product Managers. You will learn how to connect customer needs to roadmaps, write and refine backlogs, and drive value across Agile Release Trains. Explore the course today and take the next step in your product career.