A JTBD (Job To Be Done) in Catalio represents the underlying goal a user is trying to accomplish — the real reason they open a software system and start a workflow. JTBDs are the connective tissue between Personas and Journeys: they answer “why is this persona doing this journey?”
The Jobs To Be Done framework, developed by Clayton Christensen, holds that users don’t hire software for its features — they hire it to accomplish a specific job. Understanding those jobs is the key to understanding whether a system is succeeding or failing.
The Three Dimensions of a JTBD
Catalio captures three complementary dimensions of each job:
Functional job — The practical task the user is trying to complete.
“Process and approve an accounts payable invoice for payment.”
Emotional job — How the user wants to feel while doing it.
“Feel confident that the invoice is correct and approved without needing to check with a manager.”
Social job — How the user wants to be perceived by others.
“Be seen as efficient and accurate — someone who never lets invoices sit in a queue.”
Capturing all three dimensions produces a richer picture of user needs than functional requirements alone.
Key Fields
| Field | Purpose |
|---|---|
| title | Short label for the JTBD, e.g. “Approve an AP Invoice” |
| statement | Full JTBD statement in narrative form |
| functional_job | The core task the user is performing |
| emotional_job | How the user wants to feel |
| social_job | How the user wants to be perceived |
| persona_id | The Persona this JTBD belongs to |
| status | Lifecycle: draft, validated, archived |
| organization_id | Tenant scope |
JTBD Lifecycle
draft → validated → archived
draft — The JTBD has been identified but not yet confirmed through discovery. It may be based on assumptions or preliminary stakeholder input.
validated — The JTBD has been confirmed through user interviews, journey observation, or other discovery methods. Journeys and comparisons anchored to validated JTBDs carry more weight in business cases.
archived — The JTBD is no longer relevant (role changed, process eliminated) but is preserved for historical reference.
JTBDs and Personas
Every JTBD belongs to a Persona. The Persona represents who the user is; the JTBD represents what they are trying to accomplish.
A single Persona typically has multiple JTBDs:
Persona: AP Clerk
JTBD: "Process a vendor invoice for payment"
JTBD: "Reconcile a batch of invoices at month-end"
JTBD: "Resolve an invoice discrepancy with a vendor"
JTBD: "Generate an AP aging report for the finance manager"
JTBDs and Journeys
A Journey can be linked to a JTBD (jtbd_id is optional on the Journey resource). This linkage answers: “This is the sequence of steps the AP Clerk follows when trying to process a vendor invoice for payment.”
Multiple Journeys can share the same JTBD — for example:
- Journey A: Legacy system (Oracle EBS) — AP invoice processing — baseline
- Journey B: New system (target SaaS) — AP invoice processing — target
Both journeys address the same JTBD. A Journey Comparison compares Journey A and Journey B to quantify the improvement in accomplishing that JTBD.
Writing Effective JTBD Statements
A good JTBD statement follows this pattern:
“When [trigger context], I want to [motivation], so I can [expected outcome].”
Example:
“When a new invoice arrives in my queue, I want to quickly verify it against the purchase order and approve it for payment, so I can ensure vendors are paid on time and avoid penalty fees.”
This is richer than “User wants to approve invoices” because it includes the trigger (invoice arrival), the motivation (verify and approve), and the outcome (on-time payment, no penalties).
JTBD Journey Counts
Catalio tracks journeys_count as a calculated aggregate on JTBD records. JTBDs with zero journeys have no empirical coverage — they represent assumed user goals without behavioral evidence. Prioritize capturing journeys for high-priority JTBDs with zero coverage.
Best Practices
Derive JTBDs from observation, not assumption.
The best JTBDs come from watching real users work, not from asking managers what users do. User behavior in a legacy system often diverges dramatically from documented process.
Start with 3-5 JTBDs per key Persona.
Don’t try to enumerate every possible job. Focus on the JTBDs that are most frequent, most painful, or most strategically important.
Validate before anchoring journeys.
Capture journeys against draft JTBDs, but prioritize validating JTBDs with actual users before using them as the basis for business cases or investment decisions.
Use emotional and social jobs in communications.
When presenting to stakeholders, emotional and social job language lands better than functional descriptions. “Users feel anxious every time they submit an invoice because they don’t know if it will bounce back” drives more urgency than “the approval workflow has 23 steps.”
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Personas | JTBDs belong to a Persona |
| Journeys | Journeys can be linked to a JTBD when one applies |
| Journey Comparisons | Comparisons measure JTBD fulfillment before and after when a JTBD is linked |
Next Steps
- Define Personas — Create the user roles that have JTBDs
- Capture Journeys — Record how users accomplish JTBDs in practice
- Compare Journeys — Measure improvement in JTBD fulfillment
Pro Tip: The most revealing moment in JTBD discovery is when a user describes a job that does not match any documented process. That gap between what users are actually trying to accomplish and what the system was designed for is often the root cause of widespread friction.
Support
- Documentation: Continue reading about Personas and Journeys
- Email: support@catalio.ai
- Community: Share JTBD discovery techniques with other Catalio users