What Is Job-to-Be-Done (CX) in Customer Experience?

What is job-to-be-done (CX)?

Job-to-be-done (CX) is a customer-research concept that describes the progress a person or organization is trying to make in a particular situation, including functional, emotional, and social needs that influence the decision.

A job is broader than a task or feature. “Submit an order” is a task; “secure the right replacement before production stops” describes the progress the customer is trying to achieve. Different products, services, workarounds, or human assistance may all compete to help complete the same job.

For CX teams, JTBD shifts the design question from “What feature does the customer want?” to “What outcome is the customer trying to achieve, under what circumstances, and what prevents that progress today?”

How job-to-be-done (CX) works

The jobs-to-be-done framework investigates why customers choose, switch, or stop using an offering. It separates the desired progress from the current solution, helping teams consider alternatives that a feature request or demographic profile might overlook.

Circumstance and trigger

Identify what was happening when the need became important and what prompted action. A useful job is specific enough to explain a decision, rather than a broad aspiration such as wanting convenience.

Desired progress

Describe the outcome and how the customer recognizes success. Include practical results alongside concerns such as confidence, reduced anxiety, or professional credibility where research supports them.

Alternatives and trade-offs

Investigate current workarounds, competing approaches, and barriers to switching. An organization may compete with a spreadsheet, a phone call, or doing nothing rather than only with similar software.

what-is-job-to-be-done-cx-and-how-it-works-kyanon-digital — The JTBD framework maps a customer’s specific situation and trigger directly to their desired progress and available alternatives to guide experience decisions.

How do you identify a real customer job?

A useful job should come from evidence about a real decision or struggle rather than an internally invented statement.

Research should investigate:

Trigger: What changed and made the customer start looking for a solution?
Current approach: How was the customer handling the situation before?
Struggle: What made the existing approach insufficient?
Alternatives: What other products, processes, workarounds, or non-consumption did they consider?
Trade-offs: What concerns made switching difficult?
Desired outcome: What would make the customer consider the situation successfully resolved?

Ask customers to reconstruct specific past decisions rather than only asking what they would hypothetically want in the future.

A polished job statement created without evidence can still encode the organization’s assumptions rather than the customer’s actual decision process.

How do you write a useful job statement?

A practical interview prompt is ‘When [situation], I want to [make progress], so I can [achieve an outcome].’ This is a writing aid, not a substitute for researching the circumstances behind a decision. For example: ‘When a delivery will arrive while I am away, I want to change the delivery arrangement so I can receive the order reliably.’

The job is broader than ‘use an address-editing feature.’ Customers may hire an alternative such as collection from a pickup point or help from another person. Ask about the trigger, previous workaround, anxieties and desired outcome. Include functional, emotional and social dimensions where the evidence supports them. Evaluate proposed features against the job rather than treating the interviewee’s first feature request as the requirement.

How is a customer job different from a task or feature?

A customer job describes the progress sought; tasks and features describe parts of how that progress may be achieved.

Concept	Example
Job	Keep production running when a critical component fails
Outcome	Obtain a compatible replacement before downtime becomes costly
Task	Search for the component
Feature	Product compatibility filter
Current workaround	Call a known supplier directly

This distinction prevents teams from treating the current interface or requested feature as the problem definition. The same job may be completed through several different journeys or solutions.

Job-to-be-done (CX) vs. customer persona

A job-to-be-done explains progress sought in a situation; a customer persona describes a research-based user group and its relevant characteristics.

Dimension	Job-to-Be-Done (CX)	Customer Persona
Primary question	What progress is the customer seeking?	Who are we designing for?
Unit of analysis	Situation and desired outcome	User group or archetype
Evidence	Decision stories and actual behavior	Research about needs and characteristics
Main output	Job, outcome, and switching forces	Representative profile
Best use	Reframe problems and evaluate solutions	Guide communication and design context

When to consider job-to-be-done (CX)

Consider job-to-be-done (CX) when the following conditions affect customer outcomes or operational control:

Customers request features, but teams disagree about the problem those features should solve
A digital service has acceptable usability yet struggles to attract or retain users
You are redesigning a journey and need to challenge assumptions about the current solution

It may not be the right priority if:

A broad jobs study may be unnecessary for a well-understood interface defect. Use targeted usability research when the customer goal is already clear.

when-to-consider-job-to-be-done-cx-kyanon-digital — Apply Job-to-Be-Done to resolve feature disagreements, tackle low user adoption despite good usability, or challenge assumptions during journey redesigns rather than for fixing straightforward interface defects.

How does JTBD translate into CX requirements?

A researched job should change a design or product decision. Translate the job into the conditions customers need to make progress rather than directly converting interview statements into features.

A practical sequence is

Situation → Job → Desired outcome → Barrier → Experience requirement → Solution → Measurement

For example:

Situation: A critical machine component fails
Job: Secure a suitable replacement before production is disrupted
Barrier: Uncertainty about compatibility and delivery time
Experience requirement: Give the buyer confidence that the selected part fits and can arrive when required
Possible solutions: Compatibility guidance, stock visibility, delivery estimates, or specialist assistance
Measurement: Successful selection, completed order, fewer compatibility-related contacts or returns

The feature comes after the customer job and experience requirements have been established. This gives teams room to compare alternative solutions instead of treating the first requested feature as the requirement.

how-does-jtbd-translate-into-cx-requirements-kyanon-digital — This example contrasts a customer’s immediate task of booking a flight with their ultimate progress of arriving at a business meeting smoothly and on time.

How should businesses prioritize customer jobs?

Not every identified customer job requires the same level of investment. Prioritization should consider both customer importance and the organization’s ability to improve the outcome.

Useful questions include:

How important is the desired outcome to the customer?
How poorly does the current experience or alternative satisfy it?
How frequently does the situation occur?
What happens when the customer cannot make progress?
Which customer or business outcomes could improve if the job is better supported?
Can the organization realistically address the underlying constraints?

A frequently mentioned request is not automatically the highest-priority job. A less frequent situation can deserve greater attention when failure has a significant customer or operational consequence.

JTBD should therefore inform prioritization rather than become a catalogue of customer needs.

Why jobs-to-be-done (CX) matters for B2B software

Jobs-to-be-done research helps B2B teams distinguish the outcome customers need from the workflow or product they currently use to achieve it.

This distinction matters because enterprise buying and usage decisions can involve several constraints beyond completing a software task: operational risk, approval, integration, confidence, timing, and accountability may all influence whether a solution is adopted.

For example, a purchasing manager facing a failed machine component may need to secure an approved replacement before production stops. The job is broader than placing an order. Compatibility confidence, internal approval, delivery timing, and a defensible supplier choice can all determine whether the customer makes progress.

Understanding that a wider job can change product priorities. Instead of simply optimizing an ordering interface, a team might discover that compatibility information, approval visibility, delivery certainty, or access to specialist assistance is the more important experience constraint.

why-jobs-to-be-done-cx-matters-for-b2b-software-kyanon-digital — Understanding that a broader B2B job involves operational constraints like approval, timing, and risk can shift product priorities beyond simple order placement.

Common misconceptions

“A job is the feature the customer asks us to build.”

Reality: A feature is one possible solution. Research the underlying progress, circumstances, and barriers before deciding which product behavior should support it.

“JTBD makes personas unnecessary.”

Reality: The tools answer different questions. JTBD explains the progress sought in a particular situation, while research-based personas can provide relevant context about users, roles, capabilities, or constraints.

“We can define customer jobs in an internal workshop.”

Reality: Workshops can organize existing evidence, but they do not replace customer research. Jobs created only from internal assumptions can reproduce the same product-centric thinking the framework is intended to challenge.

jobs-to-be-done-cx-common-misconceptions-kyanon-digital — Avoid common pitfalls by treating customer jobs as underlying progress rather than requested features, keeping JTBD separate from personas, and grounding insights in actual research rather than internal workshops.

How Kyanon Digital applies job-to-be-done (CX)

Kyanon Digital can use customer-job thinking within CX and product discovery to connect experience decisions with the outcomes customers are trying to achieve.

Research can examine customer situations, goals, current workflows, barriers, and alternative ways of making progress. These insights can then inform journey requirements, prototypes, and solution priorities rather than treating existing processes or requested features as fixed requirements.

A useful implementation path is

Customer situation → desired progress → barrier → experience requirement → solution option → measurable outcome

The objective is to ensure that digital experience investments solve a meaningful customer problem before teams commit to a particular feature or technology.

Explore Kyanon Digital’s UX design services.

Job-to-Be-Done (CX)