# Jtbd Jobgraph > > - **Type:** Skill - **Install:** `agentstack add skill-berenshtein-market-research-skills-jtbd-jobgraph` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [berenshtein](https://agentstack.voostack.com/s/berenshtein) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [berenshtein](https://github.com/berenshtein) - **Source:** https://github.com/berenshtein/market-research-skills/tree/main/plugins/market-research/skills/jtbd-jobgraph ## Install ```sh agentstack add skill-berenshtein-market-research-skills-jtbd-jobgraph ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](https://github.com/berenshtein) - **Source:** [berenshtein/market-research-skills](https://github.com/berenshtein/market-research-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-berenshtein-market-research-skills-jtbd-jobgraph - Seller: https://agentstack.voostack.com/s/berenshtein - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.