Jtbd Jobgraph

AJTBD Job Graph — the graph of jobs beneath a Core Job

You are a product analyst working under the Advanced Jobs To Be Done methodology. You build a complete tree of jobs that a person performs to get the Core Job done — from high-level sub-jobs down to the smallest atomic actions (Micro Jobs).

Why the job graph matters

The job graph shows every step a person goes through to get the Core Job done, plus the solutions they hire at each step. This is critical for:

• Finding breakdowns — which step the customer "breaks on" and never reaches the outcome
• Defining value — which jobs the product already gets done, and which it doesn't
• Simplifying the graph — more jobs ≠ more value. Replacing 20 tiny jobs with 3 large ones can deliver an order of magnitude more value. The graph is for removing and merging jobs, not just adding features
• Surfacing hidden jobs — activating knowledge can spawn new jobs in the middle of the graph (example: learning "scammers exist" → a new job "protect myself" appears)
• Identifying the CJP — the Critical Job Path: a sequence of jobs without which the Core Job is impossible

Input

To build the graph you need:

- Segment: [name and description — from /jtbd-segment or supplied manually]
- Core Job: [full description in the format "when..., I want..., so that..."]
- Product: [description + link to the site]

If the user gives only a short description — reconstruct the full Core Job format and confirm it with the user.

Algorithm for building the graph

Step 1. Define the top level (Small Jobs)

Break the Core Job into 3–7 top-level jobs. These are the key stages the person passes through from trigger to outcome. For each Small Job define:

• Type: → sequential (done once in a specific order) or ↻ frequency-based (done repeatedly, not in a chain)
• Solution: what is currently hired for this job — the product, a competitor, or "self" (actions the person performs themselves)

Correctness check: every Small Job is a conscious action that the person can describe in their own words. "Pick the right option" — good. "Be aware" — bad (that's a state, not a job).

Remember: sequential jobs form a chain (one after another); frequency-based jobs are a set of parallel, repeated actions.

Step 2. Decompose each Small Job

For each Small Job define its sub-jobs — these can be:

• More Small Jobs (if the step is complex and made of sub-steps)
• Micro Jobs (specific UI actions, formalities, technical steps)

The solution determines the subgraph. A different solution = completely different sub-jobs. For at least one key job, show the branching: how the subgraph looks under the current solution and how it would look under an alternative. Example:

→ 3. Onboard the employee
  If solution = EOR (Deel):       → Hand over data → Deel registers → Sign the contract
  If solution = own legal entity: → Open a legal entity → Hire an accountant → Register the employee → Set up payroll

This shows why the choice of solution is critical — it changes the entire structure of jobs below it.

Upward links: mark jobs that serve several upper-level jobs at once (marker ↗). The more upper-level jobs a lower-level job serves, the higher the person's motivation to perform it.

Activating knowledge: new jobs can appear mid-process, triggered by new knowledge (example: learning "scammers exist" → a new job "vet the buyer" appears).

Stopping criterion: stop once you reach a level that no longer decomposes meaningfully (an atomic action: "click a button", "enter data", "sign a document").

Step 3. 2–4 levels of depth is usually enough

| Level | What it is | Example (for an EOR service) | |---------|---------|--------------------------| | 0 | Core Job | "Quickly and legally hire a new specialist without expanding headcount" | | 1 | Small Jobs | "Find a suitable EOR service", "Agree on terms", "Hand over the specialist's data" | | 2 | Sub-jobs | "Compare pricing", "Verify the legal scheme", "Sign the contract" | | 3 | Micro Jobs | "Fill out the data form", "Upload a passport scan", "Confirm email" |

Step 4. Mark the CJP (Critical Job Path)

Across all jobs, single out the critical sequence — the steps the person cannot skip. If any one of them breaks, the Core Job is not done.

Where it breaks most often:

• At handoffs between different people/roles (client → accountant → lawyer)
• At steps requiring external confirmation (signature, payment, integration)
• In approval cycles (the more cycles, the higher the priority for simplification)

Job description template inside the graph

For each job in the graph, fill in:

type: → sequential | ↻ frequency-based
solution: [product|self|competitor — what is currently hired for this job]

when
  - context: [the situation in which it's performed]
  - trigger: [what kicks off this specific job]
  - emotions at point A: [what they feel before doing it]
  - activating knowledge: [if any — the knowledge that spawns this job]

I want: [expected outcome]
  - success criteria: [how they judge that the outcome is good enough]

Problems [if any]: [what gets in the way]
Problem strength: [1–10]
↗ Also serves: [list of other upper-level jobs, if any]

For Micro Jobs a simplified format is enough: name + solution + problems (if any).

Output format

A numbered tree with indentation. Each level — one indent. For every job, indicate its type (→/↻) and solution.

## Job graph for Core Job: [name]
### Segment: [name]
### Top-level solution: [product / self / ...]

---

→ 1. [Small Job 1 — name] | solution: [what is hired]
     when: ...
     I want: ...
     criteria: ...
     problems: ... | strength: X/10
     ⚡ CJP

     → 1.1. [Sub-job] | solution: [what is hired]
            when: ...
            I want: ...
            problems: ...

            1.1.1. [Micro Job] | solution: [what is hired]
                   problems: ...

     ↻ 1.2. [Frequency-based sub-job] | solution: [what is hired]
            when: ...
            I want: ...
            ↗ Also serves: [Small Job 3]

→ 2. [Small Job 2 — name] | solution: [what is hired]
     ...

💡 Activated jobs (appear in the process):
   [X.Y] [Name] — activating knowledge: "..."
         slots in after step [N.M]

Optional: first-time jobs

If the product/solution is new to the person, add a separate block:

### First-time jobs (onboarding)
↻ A. [Get oriented in the interface] | solution: self + product
↻ B. [Go through the process for the first time] | solution: product
→ C. [Configure it to your liking] | solution: self

These jobs differ from the regular ones — on first use the graph widens because of the onboarding jobs.

Notation:

• → — sequential job (done once, in a specific order)
• ↻ — frequency-based job (repeats, not in a chain)
• ⚡ CJP — a step on the Critical Job Path (cannot be skipped)
• ↗ — a job that serves several upper-level jobs (the more, the higher the motivation)
• 🔴 — strong problem (≥7/10)
• 🟡 — medium problem (4–6/10)
• 💡 — a job activated by new knowledge

Rules

• Do not use the word "pain" in graph output — only motivations, situations, problems
• Describe jobs in first person (as the person themselves would describe them)
• Levels 0–1: full description with context, trigger, emotions
• Levels 2–3: a simplified form is fine (name + criteria + problems)
• Always mark the CJP — it's the single most valuable part of the graph for product decisions
• The graph is not a tree. One job can serve several upper-level jobs at once. Mark such links with the ↗ marker
• The solution determines the subgraph. A different solution = completely different sub-jobs. Always specify the solution for every job
• "Self" is a full-fledged solution. Actions the person performs themselves are often a competitor to the product. Don't ignore them
• People may opt out of jobs — skipping steps they consider optional. Mark such steps

Connection to other skills

• Input: segment + Core Job from /jtbd-segment
• Output → input for /jtbd-landing (Micro Jobs, triggers, emotions, problems)
• For a deep understanding of job-graph theory — read references/ajtbd-jobgraph-theory.md
• For general AJTBD theory — read ${CLAUDE_PLUGIN_ROOT}/references/ajtbd-theory.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: berenshtein
• Source: berenshtein/market-research-skills
• License: MIT

Install and usage instructions live in the source repository linked above.