Persona and JTBD Analysis

Use during Phase 1 (GATHER) when the user lacks clear personas or the "Who" section needs rigorous definition. Provides structured alternative to ad-hoc persona descriptions.

Persona Template

For each user type, build a complete persona:

## Persona: {Name}

**Who**: {Role description -- one sentence capturing relationship to product}
**Demographics**:
- {Characteristic 1: e.g., technical proficiency level}
- {Characteristic 2: e.g., frequency of interaction}
- {Characteristic 3: e.g., environment/context of use}
- {Characteristic 4: e.g., primary motivation}

**Jobs-to-be-Done**: (see Job Step Table below)

**Pain Points**:
- {Pain 1} -- maps to Job Step: {step name}
- {Pain 2} -- maps to Job Step: {step name}

**Success Metrics**:
- {Quantified outcome 1: e.g., "Task completed in < 2 minutes"}
- {Quantified outcome 2: e.g., "Zero manual configuration steps"}

Job Step Table

Each persona has job steps describing what they accomplish. Steps follow ODI format.

Rules for Job Steps

• Job Steps are always verbs: Discover, Validate, Install, Configure, Monitor, Recover
• Goals describe what the user wants, not what the system does
• Desired Outcomes use ODI format: "Minimize [time/effort/risk/likelihood] of [undesirable state]"
• Each step maps to a workflow point where value is created or destroyed

Example Job Step Table

Pain Point Mapping

Every pain point maps to a specific job step. Pain points without a corresponding step indicate either a missing step or irrelevant pain point.

Pain Point: "I don't know if the tool supports my OS"
  -> Job Step: Discover
  -> Desired Outcome: Minimize uncertainty about compatibility

Pain Point: "Installation fails silently with no error message"
  -> Job Step: Install
  -> Desired Outcome: Minimize time to diagnose installation failures

Prioritize: pain points on high-frequency job steps deserve attention first.

Success Metric Quantification

Every success metric needs a number or threshold. Qualitative metrics ("easy to use") are not actionable.

Multi-Persona Segmentation

Different users have fundamentally different jobs even when using the same product. Segment by relationship to the product.

Common axes: Frequency (first-time vs returning vs power user) | Role (end user vs admin vs developer) | Context (individual vs team vs CI/CD) | Motivation (exploration vs production vs evaluation)

Example: Same Product, Different Jobs

Each persona gets their own Job Step table because workflows differ. Do not merge personas -- JTBD analysis value comes from surfacing differences.

Integration with Story Crafting

After completing persona analysis, feed results into LeanUX user story template:

1. Persona Who -> populated from persona template
2. Persona Pain Points -> inform story Problem section
3. Job Step Desired Outcomes -> inform AC (ODI outcomes translate to testable criteria)
4. Success Metrics -> inform NFR requirements in handoff package

Cross-reference: use bdd-requirements skill for Example Mapping once personas established. Use jtbd-workflow-selection skill to determine workflow for resulting stories.