Spruce.

§ Discovery

/jtbd

Name the jobs the personas hire the product to do.

What it does

Personas describe who the user is; jobs describe what they’re trying to accomplish. /jtbd articulates the underlying jobs — functional, emotional, social — that the personas in `.personas.md` are hiring the product to do, independent of any specific feature or solution. Output is `.jtbd.md`, read by every command that should ground feature or copy decisions in real user motivation rather than in surface-level feature descriptions.

Three layers, captured per persona. Functional jobs name what someone is trying to get done in the world. Emotional jobs name how they want to feel about it. Social jobs name how they want to be perceived. Cross-persona analysis surfaces shared jobs (designs that serve multiple personas at once), diverging jobs (same situation, different motivation), and conflicting jobs (serving one works against another) — each with downstream design implications.

Specimen

/jtbd · Stillpoint

Forward implications

What these jobs mean for design work going forward

  • Maya’s F2 (mid-day reset) argues for a fast-entry-fast-exit pattern on the mid-day surface specifically. /design should treat any flow that requires more than two taps before practice begins as a job-blocking failure for this surface.
  • Maya’s E2 (return-without-restart) rules out streak-broken UI patterns, gamification metrics, and missed-day anxiety patterns. /design and /decide should treat these as out-of-scope unless the team explicitly chooses to override Maya’s emotional job. /critique should flag any drift toward streak-language as a violation.
  • Jordan’s E1 (honest-not-packaged) means the home page’s first 30 seconds carry disproportionate weight. Almost every wellness-app cliché is a violation of this job. /voice and /critique should evaluate first-impression copy against this job specifically.
  • Jordan’s F1 (sample without commitment) means /uxreview should flag any flow requiring account creation before first practice as a Jordan-blocking failure. The product’s acquisition motion depends on this job being served well.
  • Both personas’ social jobs (S1) argue against any pattern that signals “lifestyle product” or “wellness trend.” No “join 10,000+ people” copy. No completed-practices counters. No social sharing. /design and /decide should treat features that violate this as out-of-scope unless the team explicitly chooses to override.
  • Conflict between Maya’s F1 and Jordan’s F1 will surface as a real /decide tradeoff for the home + first-practice flow design. Default resolution: design Jordan-friendly orientation that Maya can dismiss after first use, rather than choosing one persona’s pattern outright.

/jtbd writes .jtbd.md — the underlying jobs each persona is hiring the product to do, articulated in the canonical When / I want to / So I can structure. Cross-persona conflicts surface as deliberate /decide tradeoffs rather than averaged away.

When to use it

  • Personas exist (`.personas.md`) but feature decisions feel disconnected from underlying user motivation.
  • Multiple legitimate features could be built and you want a way to evaluate them against real user jobs.
  • Copy is drifting toward feature descriptions (“Manage your projects with our tool”) rather than job descriptions (“Settle the day’s loose ends before they become tomorrow’s problem”).
  • You want cross-persona conflict to surface as design tradeoffs rather than getting averaged-away in implementation.
  • Preparing to /design or /decide a new feature and want to ground the decisions in jobs rather than competitive feature parity.

How to use it

/jtbd

By default /jtbd asks which mode to run — drafting from `.personas.md`, structuring supplied research, or pressure-testing an existing file. Every job names its confidence so downstream commands can weight it. Output is `.jtbd.md`, organized by persona with cross-persona analysis at the end.

  • /jtbd update
  • /jtbd pressure-test

Anti-patterns it addresses

  • Feature descriptions disguised as jobs (“Use the calendar to schedule meetings”). A real job is solution-independent — it would still exist if the feature didn’t.
  • Functional jobs only, no emotional or social. The functional layer is the easiest to articulate but the most generic; the emotional and social layers are where character-driven design decisions live.
  • Jobs that don’t connect to any persona. Floating jobs without a named user can’t be evaluated — every job should belong to a specific persona doing a specific thing.
  • Cross-persona conflicts averaged away rather than surfaced. The value of /jtbd is naming the conflicts so /decide can address them deliberately, not hiding them in a compromise neither persona wants.
  • Stock JTBD framings (“I want to save time and reduce friction”) that could apply to any product. Specificity is the point — jobs that could be on any company’s website aren’t doing design work.

See also